Dependency graph using continue_msg, but need limit on concurrency like function_node has

[cracauer]

Hi. I am using tbb to resolve a dependency graph using continue_msg. Working great, except that I need to be able to limit the number of concurrently executing node bodies like function_node can.

Is there a particular reason why continue_msg graphs don't have this capability? Did it just not come up yet, or is there a hard obstacle?

On a possibly/probably related note, I do not understand the example in https://oneapi-src.github.io/oneTBB/main/tbb_userguide/use_concurrency_limits.html and how function_node and continue_msg relate to each other in there.

[kboyarinov]

@cracauer,

Thanks for your question.
I don't know the exact reason why continue_node was not extended to support the concurrency limit.
@vossmjp, @aleksei-fedotov, do you know something in that regard?

Is there a reason why function_node<continue_msg> cannot be used for this purpose?

Regarding the example you shared, I will try to explain it in more details. In that example, the input_node and function_node together are using a so-called push-pull protocol for forwarding messages (See more details here).
The input_node generates one big_object each time the node body is executed and tries to forward it to the function_node. Since the function_node has the rejecting policy and concurrency limit equal to 3, the first three big_objects woud be accepted to work with. But when the input_node will try to broadcast the next big_object, the function_node would reject it. In that case, the input_node would work as a buffer of capacity 1, it will buffer the big_object internally and the edge between the input_node and function_node would be set in so-called pull-state. It means that when the function_node finish working on one of previously submitted object, it will try to get the "postponed" object from the input_node calling try_get() method on it which will return the item buffered in the input_node. input_node will continue executing the body and generating more big_objects, but the maximal number of object in work for function_node would be limited to 3.