I've been working on a paper design for a flow graph and am having difficulties getting something clean, but have an idea of how a hopefully simple TBB addition would make my problem easier.
Basically, I have a graph where a serial multifunction node M is feeding a function node F (which may be serial as well). Node M may generate between 1 and 3 inputs to F for every input it receives.
... -> M -> F -> ...
Now, I don't want a lot of buffering in this network -- I'd rather not have any at all -- but clearly, if I generate 3 things from one thing, there has to be a buffer somewhere. Most likely, this is a queue node between the multifunction node and the function node. I also need a limiter node L in front of M to keep it from being overfed.
... -> L -> M -> Q -> F -> ...
Since M's body can't control whether or not the node accepts input, I can't put a limiter node in front Q. Now, what I'd like to be able to do is decrement the limiter node L when the function node F has accepted everything that M put into the queue Q since M got an input, but there isn't any obvious, clean way to do that -- the only way I've been able to come up with is to clutter up the output from M with some sort of "end of sequence" marker that F (or a new node between Q and F) can use as an indicator to call F's decrementer.
So, the question: Is there any better way to do this?
The hopefully simple addition: Could queue_node be extended with an additional output port on which it could send a continue message when it is empty? If that extension were in place, the continue-message output of the queue node could be wired to the limiter node's decrement member. Then the graph above could regulate itself without any additional management on the part of M and F.
Actually, just to make the addition more complicated, you'd like to be able to apply this functionality to any node that buffers its input (priority queue nodes, sequencer nodes, etc.). Maybe this addition could be written as a decorator rather than cluttering up all those nodes' APIs. Also, It Would Be Nice If the threshold at which continue messages get generated were configurable -- that is, let the queue send continue messages when it has fewer than n elements rather than waiting until it gets down to zero.