Front page | perl.perl5.porters |
Postings from August 2021
* Nicholas Clark <nick@ccl4.org> [2021-08-03 13:01:48 +0000]: > 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: > https://www.python.org/dev/peps/pep-0554/ > > (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 Understanding that "perl" is a uniprocess and that Perl tempts us into wanting concurrency is a crucial point to blast through the cognative dissonnance, reconcile what we have versus what we want, and then move forward in various approaches fully and openly. This was the main point that I wanted to make with my conference talk on sequential consistency, and why it's a valuable concept for undertanding the true state of things. It will save us from spending too much time on things that fundamentally don't make any sense. Cheers, Brett -- -- oodler@cpan.org oodler577@sdf-eu.org SDF-EU Public Access UNIX System - http://sdfeu.org irc.perl.org #openmp #pdl #nativeThread Previous | Thread Next