Sucked into a general purpose threadpool!
TL;DR To paraphrase
Thoreau "Decouple, decouple, decouple!" the clumsy
component that needed to take a dequeuer is simplified to a virtual interface PPM API facilitating generalisation for PXMs. There's also a threadpool PXM so that FBP can run out of the box.
As previously stated the primary strategic goal here is that the libfbp implementation of Flow-Based Programming (FBP) as a Parallel Programming Model (PPM), though the FBP paradigm is a lot more more than simply a PPM, should be agnostic to its underlying Program eXecution Model (PXM) but must, never-the-less, provide an Application Programming Interface (API) that remains versatile in its implementation.
In an effort to achieve this goal the original component
here was overly complex and took on too much of the scheduling burden the simplified component presents a single
virtual operator()() member function that returns a
component*. The API contract is simple, the returned
component* points to the next component to be executed and a returned value of
null_ptr removes the component from the execution pipeline.