Ancient “immediate-first-stage” problem

[ELLIOTTCABLE]

In the current design, you have to immediately advance a pristine execution for the first time after creating it, before it can accept the first ‘parameter’ (because a resumption-value given to a pristine execution is disregarded.) In addition, in the common ‘coproduction’ pattern, the very first parameter given (because of the above, the value of the second explicit-resumption) will be the consumer / ‘caller.’

Taken together, this means that the very first staging must be asynchronous; as our pristine execution will not have received a handle on the consumer yet, to re-stage them in a quasisynchronous style. This, however, implies a race-condition: what if we need to use our new execution ‘soon’ after initializing it? There's no way of the caller ‘knowing’ when this new execution has moved-forward to the first ‘hole,’ and is prepared to accept the first coproductive-parameter (usually, ourselves.)

---

In similar situations, we have an ‘out’ in that we can use ownership to communicate completion/preparedness: with a shared mutex-execution, we can own something, give ownership to the mutexecution, discard ownership ourselves, and then immediately block against that same ownership again. Whenever somebody else holding that mutex advances it to completion, the ownership will be discarded, signalling some event that we were waiting for, and allowing ‘us’ to continue.

This doesn't work in our situation, though, for the same reason that we can't simply treat this synchronously: we can't have gotten any data into the pristine target yet, including such a shared mutex.

[ELLIOTTCABLE]

(This is blocking work on examples/**-coproduction.paws and examples/**-implement.assignment.paws. Also, the direct consequence of those, which is beginning work on a cPaws “tutorial” / walkthrough.)

[ELLIOTTCABLE]

Hint of an idea … using the execution itself as aforementioned mutex. (But doesn't staging something require ownership of it?)

[ELLIOTTCABLE]

further alternative, although not an excellent one: block the creator of a new execution by default, and immediately/synchronously execute the new one up until it unstages itself.

Or, related … why is this a problem? At current, I can't actually remember why I was concerned about this. If the original copy is staged too soon, that staging will just sit in the queue, and then execute when the pristine-execution is complete, no?

… of course, that comes back around to a ton of the serious problems with indiscriminate holes … that means that until it unstages to coconsume it's first parameter, it can't unstages for ANY OTHER REASON. Which, in paws, is impossible to control, basically. ಠ_ಠ