The libdispatch is one of the most misused API due to the way it was presented to us when it was introduced and for many years after that, and due to the confusing documentation and API. This page is a compilation of important things to know if you're going to use this library. Many references are available at the end of this document pointing to comments from Apple's very own libdispatch maintainer (Pierre Habouzit).

My take-aways are:

• You should create very few, long-lived, well-defined queues. These queues should be seen as execution contexts in your program (gui, background work, ...) that benefit from executing in parallel. An important thing to note is that if these queues are all active at once, you will get as many threads running. In most apps, you probably do not need to create more than 3 or 4 queues.

• Go serial first, and as you find performance bottle necks, measure why, and if concurrency helps, apply with care, always validating under system pressure. Reuse

The libdispatch is one of the most misused API due to the way it was presented to us when it was introduced and for many years after that, and due to the confusing documentation and API. This page is a compilation of important things to know if you're going to use this library. Many references are available at the end of this document pointing to comments from Apple's very own libdispatch maintainer (Pierre Habouzit).

My take-aways are:

• You should create very few, long-lived, well-defined queues. These queues should be seen as execution contexts in your program (gui, background work, ...) that benefit from executing in parallel. An important thing to note is that if these queues are all active at once, you will get as many threads running. In most apps, you probably do not need to create more than 3 or 4 queues.

• Go serial first, and as you find performance bottle necks, measure why, and if concurrency helps, apply with care, always validating under system pressure. Reuse

The shorewall documentation explains in http://shorewall.org/Docker.html how to configure shorewall for use with docker. The problem with the configuration is that it only allows connections from the host to the main bridge docker0. Connections to other networks on dynamically created bridges, with names starting by default with br-, is blocked. Instead of the recommended contents of /etc/shorewall/interfaces, use wild-card interface names as follows:

#ZONE	INTERFACE	OPTIONS
#dock	docker0		bridge     # disabled default recommendation
dock 	docker0		physical=docker+,routeback=1
dock 	br		physical=br-+,routeback=1

This approach uses update-alternatives to manage GCC and LLVM/CLANG C/C++ compiler toolchains. Although tested on Linux Mint 18.3, this approach should work on any Debian based distro or for that matter any Linux distro with update-alternatives support, provided the packages are installed correctly.

There are 3 files

• gcc-alternatives.sh installs GCC versions 5/6/7 and sets up alternatives for gcc/g++/cpp/gfortran.
• llvm-clang-alternatives.sh installs LLVM and CLANG versions 4/5 and sets up alternatives for various LLVM and CLANG programs including clang and clang++.
• cc-alternatives.sh sets up alternatives for the cc, cxx, and the ld commands. This script can be used to change systemwide default compiler/linker combination to either GCC or CLANG.

Once these scripts are run you can change the system GCC/CLANG versions by running sudo update-alternatives --config gcc|clang. To change the default compiler/linker combo used by t