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