Emergent Cascading Distributed Termination - Graceful shutdown for libfbp

Lets stop monkeying around with termination in FBP 

TL;DR Herein proposed Emergent Cascading Distributed Termination (ECDT) whereby the libfbp component, viewed as an isolated push down automaton(PDA)[1], either:

• Reaches its own internal accept/final state and, as part of removing itself from the execution model's purview,  closes all its connection(s).

or

• Reacts to the closed exception(s) thrown by its connections(s) and reaches its own alternative, or only in some cases, final state and, as part of removing itself from the execution model's purview,  closes all its remaining connection(s).

and so on.

Thereby gracefully, and yet unknowingly, cascading the closed connections through the program graph ensemble of components allowing each to reach their final state and spread the cascade.

In order to retain the fungibility and black-box isolation requirements of FBP a component's terminating behaviour must be both dependency inverted, from an OOP perspective, and non-cooperative from a CSP theory perspective. With these immutable axioms in hand how then might libfbp not only terminate but do so gracefully?

C++11 Variadic template factory member function fun! Building a FBP directed graph class.

photopin cc

Better by variadic design?

TL;DR The libfbp library needs a directed graph container for the ensemble of communicating components that makes FBP programming as easy and error free as possible. Achieving these goals by giving the directed graph class the responsibilities for creation, storage, lifetime and execution of its components and connections poses the challenge of how to implement generic factory methods that allow the creation of a zoo of unknowable components and connections?  C++11/14 variadic template metaprogramming to the rescue!

Template Metaprogramming is cool! Using C++11 template overloading to make sense of queue behaviour.

photopin cc

Metaprogramming putting meat on the bones.

TL;DR Using an enumerated type as a behaviour selector at compile time by using template overloading[1] to select either total or partial queue access[2] behaviour whilst maintaining the same queue ADT interface 

The libfbp design goal is for a uniform queue interface as per the prescribed Abstract Data Type definition here using only enqueue and dequeue access class functions instead of having separate class function method calls for either partial or total access behaviour i.e. to get rid of try_enqueue and try_dequeue.