Race-condition in examples/09?

[ELLIOTTCABLE]

There's a possibly substantial problem, pointed out by @judofyr, in this code from examples/09.a.routine.paws:

implementation void()

  “Provide a shortcut to `infrastructure`”
 ( infrastructure execution stage()
      (infrastructure affix() (locals))
      (infrastructure empty())                                                )
 ( infrastructure execution stage()
      (infrastructure charge() (locals))
      (infrastructure length() (locals))                                      )

There's nothing to guarantee, on a fast-enough pair of hardware-parallelized stages, that the first-stage()'d execution will finish before the second; which means that length() could return the old length, before the affixment has completed.

Figure out how to circumvent this inside our current semantics.

[devyn]

This is still an issue, by the way, and I've run into it with Paws.rs a little bit. I'm actually not even sure why the examples run just fine on the parallel reactor, because they shouldn't... but maybe things are just executing so quickly that it ends up working?

[ELLIOTTCABLE]

Well, this is exactly the thing that, if you look at it one way, stops being an issue, if we're discarding ordering anyway. All this issue is really saying is that the implicit-ordering system that sort of exists in the current spec, really provides nothing useful: if the above example is so flawed that we need to invoke responsibility to make it predictable (which, by the way, is the solution that jumps out at me) … then why not require responsibility in the first place?