The future of 'interpreter-based threads' in perl

[Mark Martinec]

MM> I wonder if FreeBSD has any say in this perl developers decision.
Kurt Jaeger wrote:
> Probably not much. Have you raised this issue on the relevant
> perl mailing lists ?

I tried to subscribe to the perl5-porters mailing list
( http://lists.perl.org/list/perl5-porters.html ), twice.
I do receive a confirmation request from a mailing list manager,
to which I reply (or visit the provided customized link),
but then nothing happens, it gets ignored. No idea why the
ezmlm does not like my email address, despite it promptly
sending a challenge/confirmation request there. ( yes I did
check out mailer logs and content filter :)


MM> And if not, what are the plans to keep compatibility with existing
MM> multithreaded applications without being locked down to some
MM> stale version of perl.
Kurt Jaeger wrote:
> In the long run, it will ask too much from the FreeBSD community
> to support a feature that the language developers themselves chose
> to no longer support. So please communicate the issue to the
> language developers.
> 
> P.S.: I'm a perl guy, but your problem description looks like
> go might be a solution ?

It it were a larger project, then yes, go is nice, or perhaps
even erlang. But when one has most of the necessary infrastructure
already comfortably developed/coded in perl, which just needs a bit
of extra functionality in decoupling few relatively straightforward
I/O and processing tasks, it's hard to justify adopting a new language
and starting afresh. Perl has a well established stay in FreeBSD ports
(even with a nice coexistence with CPAN), which young and/or more
esoteric languages may lack.

   Mark



> 2014-12-09 Mark Martinec wrote:
>> [...]
>> That reminds me of a question I have been brewing for some time now.
>> 
>> As far as I can tell, all four lang/perl5.* ports have by default
>> option THREADS (Build threaded perl) enabled by default.
>> Don't remember when it became a default in ports, must have
>> been at least a year ago.
>> 
>> Which is very nice. I got accustomed to it, at our site we have
>> developed a couple of in-house applications that make good use
>> of perl ithreads. In some cases these interpreter threads save a
>> lot of complexity (like managing a herd of cooperating processes,
>> message passing & queueing). The price is a potentially somewhat
>> larger memory footprint (multiple interpreters) and a due care needed
>> when one has to deal with shared variables, locks and queues.
>> 
>> All in all, this feature can be very valuable.
>> 
>> But now, just as we have started depending on it, the perl
>> docs say (perl5200delta, ):
>> 
>>    Interpreter-based threads are now discouraged
>>      The "interpreter-based threads" provided by Perl are not the 
>> fast,
>>      lightweight system for multitasking that one might expect or hope
>>      for.
>>      Threads are implemented in a way that make them easy to misuse.  
>> Few
>>      people know how to use them correctly or will be able to provide
>>      help.
>> 
>>      The use of interpreter-based threads in perl is officially
>>      discouraged.
>> 
>> 
>> I don't buy arguments 'makes them easy to misuse' and 'few people know
>> how to use them correctly'. Yes, multithreading has its share if
>> implications that require more careful design. But at the same time
>> for certain near-real time applications it can be a very valuable 
>> tool.
>> 
>> I wonder if FreeBSD has any say in this perl developers decision.
>> And if not, what are the plans to keep compatibility with existing
>> multithreaded applications without being locked down to some
>> stale version of perl.
> 
> I agree with Perl. In fact wheel manufacturers should take their lead;
> We are going to discontinue the creation, and distribution of wheels.
> We have found that it is far too easy for people to abuse wheels.
> They put them on cars, and hit other cars, or other people. They drink
> too much, and use them to drive around in cars with them...

2014-12-09 21:41, Chris H wrote:
> Don't you just *love* the Perl Police. C'mon already. This is just
> nonsense. They haven't made many friends in the past either. Many
> simply write modules to overcome such removals. In fact, I created
> Perl::Police, with the intention of it being a
> collection/collaboration effort to combine all of the silliness that
> comes out of such decisions to remove such valuable resources from
> Perl. It might be a bit trickier adding threads back in via a
> module. About the easiest way I can imagine, would be to create
> a module that requires everything from base, along with the addition
> of threads. But that ends up just being another Perl version/branch. So
> probably won't help here. But I couldn't help but chime in. I
> *sincerely* hope threads don't get removed.
> 
> Thanks for the "heads up", Mark.
> --Chris