Date: Wed, 10 Dec 2014 02:14:41 +0100 From: Mark Martinec <Mark.Martinec+freebsd@ijs.si> To: ports@freebsd.org Subject: Re: The future of 'interpreter-based threads' in perl Message-ID: <956ca0fa6be3b243c909feee133a95c5@mailbox.ijs.si> In-Reply-To: <596633645e643d0bb6f489f766b8566e@ultimatedns.net> References: <bef1c1b227a6d8073809b6e49395ad9a@mailbox.ijs.si> <596633645e643d0bb6f489f766b8566e@ultimatedns.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?956ca0fa6be3b243c909feee133a95c5>