Define happens-before relationships for side-effect nodes

[RunDevelopment]

We currently have no real way for users to decide on an order in which nodes with side effects are to be executed. As we add more nodes with side effects (e.g. nodes that interact with the file system), we need more control over the order of side effects.

The most basic form of control over side effects are happens-before relationships. I.e. side effect A is guaranteed to occur before side effect B.

In chainner, we use edges to denote inputs necessary for nodes. As such, the nodes that produce those inputs necessarily have to be executed before the nodes that need their outputs. Ignoring optimizations, this is the mental model with which users make chains in chainner. I propose to use the same mechanism for side effects, since side effects are tied to nodes.

This means: If node A is upstream of node B, then side effect A happens before side effect B.

Switch

This definition of a happens-before relationship conflicts with the current implementation of the Switch node. Since the Switch node only returns one of its inputs, an optimization currently removes the edges of all other inputs. Since edges are removed, so are the happens-before relationships. (Note that side effect nodes upstream of Switch are always executed.)

Should we consider this a bug in the Switch optimization, or should we go with a different definition for happens-before relationships?

@joeyballentine

[joeyballentine]

This isn't going to only be a problem with the switch node. If we ever have proper branching, this will also be an issue.

I think there's an easy answer, which is that certain nodes (like switch or any branching nodes) "reset" the context of the chain, in that you can think of their downstream nodes as a separate chain from their upstream nodes, that run in a particular order (upstream first, then downstream)

[RunDevelopment]

If we ever have proper branching, this will also be an issue.

Not necessarily. We already talked about the idea of using iterators (or other containers like Option<T>) with 0 or 1 elements to facilitate branching. This would make branching a separate issue from happens-before relationships.

The goal of this issue is to discuss the semantics of side effect ordering. Yes, this comes up for certain implementations of branching, but not exclusively. E.g. #2555 also needs to know the exact semantics to be implemented correctly (the optimization I want to implement essentially take a Pass Through node with N inputs and splits it into N Pass Through nodes with 1 input each).

[...] certain nodes (like switch or any branching nodes) "reset" the context of the chain, in that you can think of their downstream nodes as a separate chain from their upstream nodes, that run in a particular order (upstream first, then downstream)

Firstly, the sub-chains upstream and downstream of a node (e.g. Switch) can also be connected otherwise, which makes them impossible to separate. Secondly, if I understand you correctly as saying "given a node N, anything before N must be executed before N and anything after N must be executed after N", then this isn't anything new, because it's equivalent to my statement of "if node A is upstream of node B, then side effect A happens before side effect B."