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.
Mark
_______________________________________________
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"