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 28, 2021 18:06
Subject:
Re: concurrency list (was Re: Relinquishing Maintenance of CoreModules)
Message ID:
20210728180553.GI28661@odin.sdf-eu.org
* shmem <gm@qwurx.de> [2021-07-28 19:32:05 +0200]:
> > From the keyboard of Ovid via perl5-porters [28.07.21,15:26]:
> 
> > On Sunday, 25 July 2021, 18:06:16 CEST, Oodler 577 via perl5-porters
> > <perl5-porters@perl.org> wrote:
> > 
> > > The ideas of "practical" concurrency is way more important to
> > > perl/Perl's future than virtually any other issue. This includes
> > > Perl OOP.
> > 
> > For what it's worth, I think I agree with this sentiment. We have mostly working, if
> > crippled, OOP. We don't have practical concurrency in a meaningful form. And I know one
> > company that is dumping Perl for Java because, quote "Java can use all of the cores"
> > unquote. There really aren't any popular dynamic languages with a properly working
> > concurrency model (Raku's awesome, but I don't think it's "popular"). We need useful/easy
> > concurrency, though I'm unsure if we'll get it. 
> 
> Last time I looked there was MCE which somehow looks meaningful.

MCE is useful, but it merely provides a communication fabric for
OS processes.

We also have message passing and "async" options.

What we need is a door into the sharing of memory; if not among
threads (not my goal), surely amoung fork'd processes. Coupled with
atomic synchronization primatives (which we have in some form via
sysopen), this would provide us a path to utilize forks+shared
memory.

I believe there exist some potential pathways to this. One is by
leveraging some aspects of fork (e.g., filehandles remain shared)
and also by looking at some interesting modules on CPAN.

Based on Leon's CPAN repertoire, I think that the expertise is most
certainly among us to present some interesting things.

In this vein, I am making progress on how we could leverage OpenMP
in various perlish and not so perlish ways.

But I digress, a "concurrency" list would certainly be the right
place to do these kinds of explorations. And also maybe just focus
on doing cool things for the good of Perl/perl and not fighting about
what's fake and what's real. :-)

The primary question here is - what's the next step for creating a
collaborative effort amount "all the concurrencies"? Keep in mind,
and true to form, and place would necessarily need to allow parallel
models and approaches to "concurrency". (pun 100% intended).

Cheers,
Brett
> 
> > That being said, it's not a zero-sum game. Useful OOP will still be a huge game changer.
> > Give me:
> > 
> >  *  Concurrency
> >  *  OOP
> >  *  Signatures
> >  *  Some way of defining enforceable types
> > 
> > With that, Perl can come out of the gate swinging.
> > 
> > Best,
> > Ovid
> > -- IT consulting, training, specializing in Perl, databases, and agile development
> > http://www.allaroundtheworld.fr/. 
> > Buy my book! - http://bit.ly/beginning_perl
> > 
> > 
> 
> 0--gg-
> 
> -- 
> _($_=" "x(1<<5)."?\n".q·/)Oo.  G°\        /
>                               /\_¯/(q    /
> ----------------------------  \__(m.====·.(_("always off the crowd"))."·
> ");sub _{s./.($e="'Itrs `mnsgdq Gdbj O`qkdq")=~y/"-y/#-z/;$e.e && print}


-- 
--
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