morungos.com

Let's be honest, Perl's threading model is not that good. In fact, it is for me the weakest area of the language. Generally, one of the main reasons I build and use my own Perl on Windows is so that I can remove it. And I remove it on UNIX too, but there I don't even miss it because at least I still have fork().

The issue cropped up recently on the Catalyst mailing list. Catalyst is often used with Apache, and can prefork a number of worker processes, using the threading system. In theory this is great: the code is parsed and loaded once, and then the worker processes are forked from it. The biggest drawback of not using threads on Windows is that each worker process needs to start from a clean interpreter, and this can take a good few seconds to get the application started. Doing this ten times over (if you have ten worker processes) is, to put it bluntly, crazy.

The fact that Windows benefits from fork() emulation is one thing: the issue is, should it be the same thing as threads. Threads are normally light, yet in Perl, using them essentially clones the entire interpreter state, not necessarily using the elegant copy-on-write semantics of a modern UNIX fork(). Threads are normally a good way of sharing stuff between processes, and even that is somewhat clunky in Perl.

Perl's use of 'multiplicity' is a great base - it allows multiple interpreter contexts, which really is the important bit. It would be nice to have that and a kind of object-based threading system that dispenses with the whole fork() emulation style threading crap. It would also be good for threads to have some OS basis, so that really they tapped into the benefits of whatever OS support you have -- that could be harder to deliver, but worth a try.

Sure, this means a little more programming and a little more care. Possibly even a little less portability. Probably better performance for the most part, but I'm more concerned that this runs counter the design approaches that Perl usually follows.

The thing about Perl is: it really taps into the underlying system -- that's the nature of the language. Threading seems to me a big false step -- it fakes a part of the underlying system to make systems appear more uniform that they actually are. That would be a Lisp- or Java-like approach, not a Perl-like approach.