develooper Front page | perl.perl5.porters | Postings from April 2021

the challenges of implementing multi-process programming models in auni-process environment

B. Estrade
April 12, 2021 07:55
the challenges of implementing multi-process programming models in auni-process environment
Message ID:
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., 

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 Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About