Why is Perl usually installed without thread support?

Question

Perlbrew installs per default Perl without thread support. Is this just a legacy habit or could a Perl installation with thread support generate problems?

Answer 1

Compiling Perl with thread supports adds a lot of overhead due to all the locking, even if you don't use threads in your program. I measured about 15% overhead for a simple benchmark just by using Perl compiled with threads support.

Answer 2

Because it isn't robust and performant enough to be the default.

Besides that, you have to consider CPAN. There are too many modules written in C without concern for threads.

I say this with all due love and respect as an ex-Perl6 / Parrot developer. Perl5 wasn't designed from the ground up with threading in mind (at least when I was involved in the community).

At this point, I don't think enough people care to change it. The future was going to be Perl6, and Parrot had threads very early. To destabilize Perl 5 at this point in its lifecycle is probably questionable.

It isn't like Perl is unique in this, Linux was the same way for a long time (as-in there was a big kernel lock that had to be dealt with). Most projects start like that, but some take it further than others before addressing it.

Answer 3

As @steffen-ultisch said, it is a performance issue.

But, if one so wish, it is possible to easily install Perl both with and without threads, so you can use the version more proper to a given script.

The perlbrew installation, say for Perl 5.22.1, is:

perlbrew install-multiple 5.22.1 --both=thread

Answer 4

From perl threads tutorial:

Basic Thread Support

Thread support is a Perl compile-time option. It's something that's turned on or off when Perl is built at your site, rather than when your programs are compiled. If your Perl wasn't compiled with thread support enabled, then any attempt to use threads will fail.

Your programs can use the Config module to check whether threads are enabled.

Answer 5

Perl threading is not threading in the usual sense - it actually runs a separate interpreter for each thread, so there is no shared state. A shared memory model is the main reason to use threads vs. forking processes, so Perl threads are rarely used.

Further, it is easy to end up with crashes or other unexpected behavior if you use modules that aren't thread-safe from multiple threads concurrently.

See http://perldoc.perl.org/threads.html for more.