Hi, I`m using flow graph (tbb41_20130314oss) to create an image processing pipeline, there is a queue node on input where I put a couple of images and a limiter node directly
after that, all processing multifunction nodes connect with each other if the step succeeded and to the limiter decrement if failed. Problem is
that decrementer never decrements it`s counter even though i`ve forced the first processing node to fail and it definetely sends a continue_msg,
and wait_for_all terminates after processing the amount of nodes that was supplied as a limit to the limit_node constructor. Code snippet is attached.
I think I`ve figured out why this happens. I thought that you can make many connections to the decrementer, but it only takes one, so only the last node in pipeline got connected to it.
Thanks for the note. Rereading the documentation on limiter_node I realized there is a part which is unclear.
The decrementer requires as many continue_msgs as predecessors attached to it. The graph I am attaching (limiter_node_parallel.png) shows how we envisioned it working.
When all three continue_msgs are received, the limiter decrements and if its threshold has not been reached it will forward another message.
The solution to your problem is (as counter-intuitive as it sounds) to use a broadcast_node<continue_msg> as the target of all the failure arcs from the multifunction_nodes, and make that broadcast node the only predecessor to the decrementer (see the image limiter_image_processing_pipeline.png for a schematic).
It looks like the behavior you want from the limiter_node is "or", while it was constructed with "and" behavior. We may want to add that option, or at least create an example the illustrates this.
Thanks and Regards, Chris
Thanks for making things clear. Solution with broadcast_node looks nice, although I`v already added a "failed" flag into node intercommunication structure so I just use function node as a processor and forward failed items to the last node which is connected to the limiter.
Also I think one should be careful with the limiter logic based on the count of attached predecessor,because a multifunction_node may place many continue_msg into the output port forcing the decrement even if there are other nodes attached to the limiter, which may be yet not finished.