We need to support input ports with more than one connection, which is part of the fbp standard. From the book:
Connections may have more than one input end, but they may only have one output. IPs from multiple sources will merge on a connection, arriving at the other end in "first come, first served" sequence.
In our case the order that the runtime chooses to process suspended upstream components influences the order, so it probably makes sense to execute them in the order they were connected.
The other question this feature raises is whether to allow multiple IIPs to be connected to an input, and whether to allow mixing of IIPs and component connections. IIPs are essentially components which generate a single IP before terminating (which is exactly what they are in pflow) so why should one not be able to connect multiple the same way that multiple components can be connected? I can already see use cases where we want a component to iterate over 2 or more known static values: connecting multiple IIPs would be the simplest solution.
We need to support input ports with more than one connection, which is part of the fbp standard. From the book:
In our case the order that the runtime chooses to process suspended upstream components influences the order, so it probably makes sense to execute them in the order they were connected.
The other question this feature raises is whether to allow multiple IIPs to be connected to an input, and whether to allow mixing of IIPs and component connections. IIPs are essentially components which generate a single IP before terminating (which is exactly what they are in pflow) so why should one not be able to connect multiple the same way that multiple components can be connected? I can already see use cases where we want a component to iterate over 2 or more known static values: connecting multiple IIPs would be the simplest solution.