Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.

148 newly installed, Do you want to continue [Y/n]? 3 Comments More | Login | Reply /

 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • I'm interested in your reasoning for running "Perl without threads". I've done a lot of work with developing and deploying Perl and mod_perl apps on Debian and have yet to find a reason to build my own perl executable. Does building a Perl without threading support have some advantage over the core build?
    • Actually it was a "company decision". The Perl without threads is used here for a long time. The main reason is, that in some cases Perl without threads is 10-30% faster and as we never use threads here, it's fine to disable them. Actually I would like to know who and how uses Perl threads as one can never be sure if some CPAN code is (or stays) thread safe. And probably using POE [cpan.org], AnyEvent [cpan.org] or other event loop system is much better than threads.

      • Perl threads aren’t really threads, they’re a hobbled emulation of fork() that still doesn’t work right in many cases (taint mode, anyone?). There are only two reasons to use Perl threads: 1) Windows 2) mod_perl. Both are bad ideas as far as I’m concerned. I prefer to compile Perl without threads and use fork() when I need fork().

Stories, comments, journals, and other submissions on use Perl; are Copyright 1998-2006, their respective owners.