Date: Tue, 09 Dec 2014 12:41:24 -0800 From: "Chris H" <bsd-lists@bsdforge.com> To: ports@FreeBSD.org, Mark Martinec <Mark.Martinec+freebsd@ijs.si> Subject: Re: The futuire of 'interpreter-based threads' in perl Message-ID: <596633645e643d0bb6f489f766b8566e@ultimatedns.net> In-Reply-To: <bef1c1b227a6d8073809b6e49395ad9a@mailbox.ijs.si> References: <bef1c1b227a6d8073809b6e49395ad9a@mailbox.ijs.si>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 09 Dec 2014 21:03:04 +0100 Mark Martinec <Mark.Martinec+freebsd@ijs.si> wrote > Mathieu Arnold wrote in another thread: > > Next Perl update, and plans beyond... > > As for the plans beyond that I was talking about in the subject, there > > will be a Perl 5.22 released next May, (and 5.24 the May after that,) > > when that happens, I'll change the default Perl to be 5.20, and > > deprecate 5.18 which won't, then, be supported. Sometime at the end of > > the summer, like sometime September, I'll change the default Perl to > > 5.22 and try to keep it that way, that is, a new Perl goes in in May, > > and gets to be the default in September. > > 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... 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 > > Mark > > _______________________________________________ > freebsd-ports@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-ports > To unsubscribe, send any mail to "freebsd-ports-unsubscribe@freebsd.org"
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?596633645e643d0bb6f489f766b8566e>