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

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

Thread Previous | Thread Next
Nicholas Clark
August 3, 2021 13:02
Re: concurrency list (was Re: Relinquishing Maintenance of CoreModules)
Message ID:
On Tue, Aug 03, 2021 at 01:42:41PM +0100, Dave Mitchell wrote:
> On Mon, Aug 02, 2021 at 10:39:55AM -0700, David Christensen wrote:
> >  Then threads were declared "officially discouraged".  What was
> > supposed to replace threads?
> I think "discouraging" threads was a mistake and we should undo it.
> Since that change, people have always been confusing "discourage" with
> "deprecate".
> The intent of the discouragement was more to warn people that the ithreads
> threading model may not be what they were expecting (especially that data
> is not shared by default).
> As long as people are aware of the strengths and weaknesses of ithreads,
> I see no reason why people should not continue to use it.

> For certain types of work, ithreads will give you full access to the
> parallelism provided by multiple cores. The implementation within the core
> is mature and seems mosty free of bugs (I don't recall having to track
> down a race condition for a long time now).

Unlike Python, where they are still working on implementing MULTIPLICY:

(This is not meant as a cheap shot. Far from it. It's interesting that
the history of the GIL, and Guido explicitly embracing threading early
by consciously taking a big hammer "mutex" solution, means that Python
has taken a completely different direction. As I understand it

1) the GIL means that there is no *concept* of "per interpreter", hence
   massive amounts of things really are in global C variables, and have
   to migrate to "one per interpreter"
2) the lack of encapsulated interpreter state meant that there was never
   a "allocate, create, use, destroy, release" cycle for the interpreter
   state, meaning that code does not *exist* to free some things. It's
   assumed to be taken care of by process exit

These choices are quite reasonable. It's like PERL_DESTRUCT_LEVEL=0,
hardcoded, and remove all our teardown code that only runs for level 2.

Except that they never had level 2, so now they need to write all that
code. Which we've had for 20 years.)

Nicholas Clark

Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About