multifunction_node try_put to output_port fails?

[ronag89]

What happens when a try_put to an output_port fails? Is the value lost?

[RafSchietekat]

If you don't do something else with it, that would seem to be the logical conclusion.

Trying again might cause livelock, trying again with a delay would cause undersubscription and maybe still livelock.

You could buffer the value inside the Body and try again during the next execution, or use an external buffer_node.

If you externalise you have the possibility to introduce flow control.

Disclaimer:​I think that the documentation needs some TLC, so that will be my excuse if I'm mistaken. :-)

[ronag89]

So connecting a multifunction_node to a rejecting node is probably a bad idea.

I would like to achieve something like this:

overwrite_node -> function_node with single in multiple out (i.e. multifunction_node) -> other node -> function_node

Where if the last function_node (or some other) rejects a message it will cause the overwrite_node to drop messages but any message that has passed the overwrite_node must be completed (i.e. the message can become active with a try_get).

Any ideas?

This seems to work if it wasn't for the need of the multifunction_node.

[ronag89]

Now that I think about it. multifunction_nodes are very dangerous.

If I connect a multifunction_node to a function_node with limited concurrency messages can simply disappear. Which can be very surprising to developers...

Either multifunction_node should be removed from the API or the documentation should very explicitly warn about this.

[Michael_S_]

> to a function_node with limited concurrency

You'd better say with disabled internal buffer (aka rejecting policy). A function_node with queuing policy and serial concurrency will handle all incoming messages.

Please, do not recommend removing multifunction_node. It is extremely useful. Only this node can produce any number (0 or >1) of outgoing messages per one incoming message.