Front page | perl.perl5.porters |
Postings from April 2018
On Tue, Apr 10, 2018 at 2:40 PM, Tom Molesworth via perl5-porters <perl5-porters@perl.org> wrote: >> Discouraged features aren't currently candidates for removal, but we may >> later deprecate them if they're found to stand in the way of a significant >> improvement to the Perl core. > > - surely this is the case? If we come up with a better way to implement > threads while retaining the ability for Windows to support some form of > process emulation and related features, wouldn't this be something that's > welcomed? I don't get the impression that there's widespread satisfaction > with the current state of affairs on either threads.pm or threads::shared. A crucial thing to understand in this idea is that ithreads and threads.pm are not the same thing. ithreads is a C-level feature in the implementation, threads.pm and pseudoforks are end-user level features that are built upon ithreads. One can build other abstractions on top of them. ithreads is not a good abstraction for anything resembling shared-memory architectures, but does fit a number of other concurrency models. threads::lite did proof that concept I hope. If that's not what one wants, it's probably possible to implement GIL threading instead (though I'm not sure if we'd really want that either). I think that's unexplored territory though. LeonThread Previous | Thread Next