3

I have constructed a tbb::flow::graph that consists of several function_node objects. During execution I'm passing multiple messages into the graph (from ~10 to ~100000). Sometimes one of the nodes throws an exception. If that's the case, the execution of the entire graph is cancelled, meaning all messages are discarded. However, my messages are independent from each other and I don't want their execution to be stopped.

I can catch the exception directly inside the node, but when that happens the further processing of the message won't make sense.

So my question is: how can I cancel or remove a single message from the graph without cancelling the execution of the other messages that are already in the graph?

Timo
  • 9,269
  • 2
  • 28
  • 58
  • If you catch the exception in the body of the node and handle it yourself then the graph won't be canceled. Is there a reason you can't do that? – cahuson Apr 24 '18 at 12:40
  • I am handling it in the body. But as soon as the exception is thrown, further execution of that particular message (passing the message to the node's successors) becomes irrelevant. I was just wondering if I could remove the message from the graph to remove some overhead, – Timo Apr 24 '18 at 12:46

1 Answers1

5

For the nodes that might throw an exception, use multifunction_node instead of function_node. The body functor of a multifunction_node accepts a tuple of its output ports and, unlike function_node, should explicitly put messages to these ports. Therefore multifunction_node can discard/drop messages, or create multiple outputs for each input.

Note that multiple output ports of multifunction_node do not assume a separate port for each successor. You can have a single output port and connect all successors to it; an output message will be broadcast to each successor in the same way as function_node does. Multiple output ports however allow multifunction_node not to be limited by a single type of output, making it a very flexible instrument for sophisticated message dispatch in a flow graph.

For more information about message handling by different nodes, see single-push vs. broadcast-push, other flow graph concepts, and the node behavior policies in the TBB documentation.

Alexey Kukanov
  • 12,479
  • 2
  • 36
  • 55
  • That sounds about right. The only thing that bothers me here is _"accepts a tuple of its output ports"_. Does this mean I have to know how many successors that node has at compile time? This would be a problem because the graph is generated at runtime (from a config file). – Timo Apr 25 '18 at 10:19