Front page | perl.perl5.porters |
Postings from August 2021
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 ClarkThread Previous | Thread Next