Mailing List Archive

the challenges of implementing multi-process programming models in a uni-process environment
Building upon the topics I introduced in the RFC on "Saving" perl, I
wanted to expand upon the idea that in adding semantics for
multi-process programming paradigms (async/wait, fork/join, etc); the
effort to implement this in the perl environment necessarily requires
the guarantees of sequential consistency (maybe other things also).

Q: What are the steps in defining what multi-process paradigm "x" looks
like when it's in a sequentially serialized form?

A: I have no idea; that sounds like a PhD thesis to me. But alas, this
seems to be required no matter what (I suppose given direct exposure to
the uni-process environment).

Q: Given the sequentially consistent formulation of a multi-process
programming paradigm is been done, or it's implicitly understood "well
enough" to skip to step 2 (implementation); what kind of controls of the
execution context would be most helpful in implementing the sequentially
formulation of the paradigm in a uni-process environment? (i.e.,
"correctly")?

A: It depends on what multi-process programming paradigm looks like when
it's one of potentially many sequentially consistent forms.

I invite LeoNerd to opine here, having experienced this first hand. If
you are so inclined; your insight here is invaluable IMO:

1. What has been your experience with establishing a sequentially
consistent model of async/wait; even if you've not done so formally - I
suspect this was not done nor can I currently think of an easy way to do it.

2. Given you have a pretty good idea of what the necessarily
sequentially consistent (correct) formulation of async/await after
working and thinking hard on this, what kind of "execution context"
controls would make the implementation more focused on implementing a
"correct" sequential formulation of async/await rather than dealing with
execution context? What kinds of "operations" on the execution contexts
are you finding you need in regards to what needs to be "saved" and what
needs to be "resumed"?

I have other questions, but I feel like the above is pretty heavy. It's
not loaded. I think the current insight would be supremely helpful. And
I will think about the questions above from the context of providing
fork/join semantics. I am most familiar with that model, I understand
the whole sequential consistency thing, yet I have no idea right now how
to go about "serializing" the model or if it has even been done.

But to be strictly "formal" about implementing these things in perl, I
think, is highly prudent. The alternative is to "wing it" and spend the
next 10 years chasing "bugs" with the "feature", etc. I think this
sounds familiar. And I also think that "winging it" won't get us much
further; while the formalization of what it means to implement
multi-process semantics in perl may prove to be unnecessary in practice,
I think that it's the effort to figure that out.

A final restatement of the open question is this:

Given the sequentially consistent formulation of multi-process paradigm
X, what would the use of suspend/save/inspect/resume of the necessary
execution contexts look like.

If we can't answer these questions, or learn how to answer these
questions; I am afraid we may have no business trying to extend Perl's
semantics to include the programming model - all of this necessary due
to the requirement for sequential consistency when properly presenting
something inherently multi-process.

Or maybe I'm just misreading the situation and it's really easy. If so,
I would appreciate the slap upside the head.

And not to confuse the issue, but would such capabilities be helpful in
implement MOPs or other kinds of "run times" that sit on top of the perl
run time?

Brett