I created the equivalent C code, and found that pthread_join() doesn't block deliver of the SIGALRM.

The existence of SAFE_SIGNALS in perl means that nothing you do in C is "equivalent"; and no lessons drawn from C can be applied to Perl threads.

It is also unfortunate that when Perl's threads were devised, the authors chose the pthreads api as their base, as that entire api is full of holes, anomalies and sheer bloody-minded justifictions.

For example: a useful pattern of thread usage is a fixed sized thread pool that starts a fixed number of threads doing work, and then replaces the first one to finish with another doing the next unit of work. To enable this, it would be useful to be able to issue a 'block-and-join-the-next-thread-that-finishes()' call; the logical equivalent of:

waitpid(-1, &status, 0);
[download]

But the pthreads api docs obnoxiously state:

There is no pthreads analog of waitpid(-1, &status, 0), that is, "join with any terminated thread". If you believe you need this functionality, you probably need to rethink your application design.

It's also unfortunate that development of the Perl api hasn't attempted to keep pace with the later revisions of the underlying pthreads api.

For example: If the pthreads api: int pthread_timedjoin_np(pthread_t thread, void **retval, const struct timespec *abstime); was exposed as a part of the Perl threads api, then it would go a long way to addressing your particular problem; and would permit several useful design patterns that are currently either impossible, or require elaborate hand-coding by the user to implement.

The history of threading in Perl is one fraught with short-sighted decisions and prejudices. 10 years ago I wrote The future is threaded which basically got the response: "thread is spelt 'fork'" from many directions.

I'm currently working on speeding up an elaborate piece of scientific C++ code, trying to reduce the run times from 90+ hours by an order of magnitude. I can get over one third of that reduction by simply splitting the major loops across my 4 cores threads. Another 3rd will come from hand-coding the strip-mining, loop-blocking and swizzling needed to use SSE vector operations on the code; which is tedious and laborious. The last third will have to come from careful hand-optimisations and dropping into assembler.

My old 4 core machine has seen better days; almost nothing of the original machine remains and even those parts that I've already replaced -- like the cpu fan -- are beginning to wear out. Long story short, I'm currently specing up a replacement machine based around an 8-core 4Ghz processor for £130; and if I could bring myself to paying through the nose for it I could be looking at a 20(10) core processor.

With the latter machine, I could achieve the full order of magnitude time saving just by adjusting the number of threads.

10 years on, that threaded future is now; and Perl hasn't moved forward at all. So sad.