I am trying to analyse a possible race condition. Do link nodes take time to process or are they virtual wires so messages go direct from one end to the other? If they take time to process do link in and out each take time? In other words, in terms of timing is
I've not reviewed the code but don't forget that, as long as you don't double-up wires on an output port, Node-RED isn't really "sending" a message. All it is doing is passing an object reference from one function to another. As far as I am aware, this is also true for link nodes so the overheads should be almost zero.
You would need to check the source code to see if the nodes actually process the message. A change node almost certainly will have some overheads as I would expect it to be doing some validation checks if nothing else.
I should probably have been more explicit about why I am asking the question, it isn't about overheads within a node, it is about sequencing of message handling as the flow progresses. In this flow
When A passes on a (reference to a) message it will be processed by node B and then by Node A, or perhaps the other way around, it depends on what order the nodes are wired up. Therefore it is not safe to make assumptions about which one will be run first.
In this flow, however
It is guaranteed that both B and C will be run before D gets hold of the message passed on by C.
Now if C is replaced by link nodes so we have
Then if the link nodes are just a drawing trick and the result is the same as drawing a wire directly between A and D then once again one cannot rely on the order of execution of B and D, but if they are equivalent to nodes that do effectively nothing except pass the message on then one can safely assume that B will be run before D.
No. That is not guaranteed. It is highly likely to behave as you say, but we don't make any guarantees once the flow forks.
Passing a message between link nodes uses all the same code paths as passing a message between any other two nodes. So they are not the same as a wire going from A straight to D - they are the same as having two nodes in between A and D.
it isn't actually guaranteed that the function nodes will be executed before the debug nodes? So it could actually run the top function node and debug node before the bottom function node?
The word "guaranteed" means something specific here.
In a completely vanilla Node-RED setup, then yes, you can can expect each Function node to be passed the message before later nodes in either branch.
However we will not gurantee that behaviour in all scenarios. We say you should not rely on any relative ordering of nodes once a flow forks.
For example, the hooks api we introduced in 1.2 allows for custom code to be added to the message routing path. That custom code could lead to different relative orders between branches.
OK, understood, the word guaranteed is too strong. However, since my use case is that shown in the last of my images in the second post, and I know that B does nothing unusual, it would appear that I can rely on the presence of the link nodes to ensure that by the time D gets to process the message I can be confident that B will have had it's go, which is all I need to ensure that I have not got a race condition problem. I always try to avoid the need for such precautions but sometimes that is very difficult.
I will comment the flow to make sure I don't 'optimise' it at some point by removing the links
Many thanks for the clarification.