Signalling connection, disconnection of ports to processes? -- must be separate from normal data packet communication with the process, because if the output port is disconnected, then it blocks on the output port and holds off getting any new data on the input ports once these are full. It could not receive the signal/control messages if they came in over the same path as the data packets. -> must be separate and must select on both data and control input(s).
What to do with data in the edge/connection buffer? Preserve? How to preserve?
How should a component handle disconnection of his output port and how should it continue? Block and wait? What if the output "pipe" pointer needs to be changed, but the process blocks on the write?
How do JavaFBP and NoFlo handle this?
Is there a possibility in the FBP network protocol to keep the connection (-> mainly its buffered packets) and then re-connect the loose end again?
How should a process handle incomplete input data / halfway-interrupted sequence of packets? Way to signal "give up on this sequence, get ready for new" without completely resetting the state?
or should we require that the producers of the packets stop sending? "Finish the current jobs but start no new ones", like a pause functionality. Do this using general control messages/calls ... or should components where a pause feature is needed feature a normal port called "PAUSE"? There could also be a frontend router/proxy process which accepts re-routing commands so that it should now send out to backend nodes on output[2] so that output[1] can be disconnected and the processes in that part of the network can be taken down for maintenance?
Implement:
Re-generate the connection (sender and receiver side)
Concept:
Implement:
Re-generate the connection (sender and receiver side)
...
NOTE: It is possible to share a Thread handle, a join handle a wakeup handle by putting it into an Arc and just clone the Arc reference: https://doc.rust-lang.org/rust-by-example/std/arc.html