Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Ancient “immediate-first-stage” problem #6

Open
ELLIOTTCABLE opened this issue Jun 6, 2013 · 3 comments
Open

Ancient “immediate-first-stage” problem #6

ELLIOTTCABLE opened this issue Jun 6, 2013 · 3 comments

Comments

@ELLIOTTCABLE
Copy link
Member

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
Copy link
Member Author

(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
Copy link
Member Author

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

@ELLIOTTCABLE
Copy link
Member Author

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. ಠ_ಠ

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant