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

Re: concurrency list (was Re: Relinquishing Maintenance of CoreModules)

Thread Previous | Thread Next
From:
Oodler 577 via perl5-porters
Date:
July 29, 2021 17:48
Subject:
Re: concurrency list (was Re: Relinquishing Maintenance of CoreModules)
Message ID:
20210729174744.GN28661@odin.sdf-eu.org
* Leon Timmermans <fawaka@gmail.com> [2021-07-29 19:34:38 +0200]:

> On Sun, Jul 25, 2021 at 5:26 PM Oodler 577 <oodler577@sdf-eu.org> wrote:
> 
> > The ideas of "practical" concurrency is way more important to
> > perl/Perl's future than virtually any other issue.
> 
> 
> I agree it's important, that's why I'm actually working on the issue. To be
> precise, an ithreads based (so can actually use multiple processors)
> continuation passing style (same model Go uses for its channels) module.
> 
> * ithreads
> > * forking based things
> > * async
> > * "real" threads via OpenMP/pthreads bindings
> > * perl vs Perl memory models
> > * atomicity/sequential consistency
> > * lots more stuff
> >
> 
> You appear to think that ideas are something we lack, they're not. I can
> come up with more ideas in an afternoon than I can implement in a year. In

This is not what I think; but this is a good example of how the topic of concurrency
nearly always turns into a negative exchange.

> practice, all ideas have either been already done, or are very difficult
> (or even impossible) to do. My question to you would be "what are you going
> to do to implement any of these ideas?"

I am doing 2 things:

1. continuing to develop the idea of the "perl" memory model (uniprocess) and
the Perl memory model (semantically, admits concurrency). See Sub::Genius.

2. approaching concurrency from the shared memory perspective by exploring various
ideas in order to determine how OpenMP can be most naturally leveraged on an SMP
machine. See OpenMP::Environment and Alien::OpenMP.

I'd prefer to not sour any potential for us to work together because I am additionally
interested in understanding what hidden opportunities exist for exploiting shared
memory IPC among fork'd perl processes. Seems you have quite a list of modules that
are in this area, which is great.

I hope that's sufficient to satisfy your question. Seems the my opinion that emulated
threads are "fake" is offensive to some, but it's not. It's just the only way I
know to clearly differentiate "real" shared memory threading and IPC (among fork'd
processes) from thread "emulation".

> 
> 
> > So as long as it's TIMTOWTDI, I think it's a fabulous idea. Let me
> > know where to sign up! (#concurrency on irc.perl might be a cool
> > idea, too; but maybe after).
> >
> 
> Mailing lists usually start when a cc: field gets too big (that's literally
> how p5p started back in the day), so I would suggest you start with asking
> who wants to join.

I was not the originator of this request, but your advice seems legitimate. If
this is pursued, I'll join that email list immediately.

Cheers,
Brett

> 
> Leon

-- 
--
oodler@cpan.org
oodler577@sdf-eu.org
SDF-EU Public Access UNIX System - http://sdfeu.org
irc.perl.org #openmp #pdl #native

Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About