However, if using "threads->new("StartTest")->detach" directly, there is no such problem. Why?

join() waits until the thread code completes (ie. returns or falls off the end of the sub) before returning. In your example,

1. the first thread you create waits for 6 seconds before dying.
2. the second thread waits 7 seconds.
3. the third thread waits 8. and so on.

So then your main thread waits for the first thread to die, then the second, then the third etc. But none of the threads can complete until the previous threads have returned (joined), so even when their timeout occurs, they still have to hang around for the main thread.

And remember, threads are non-deterministic. That means that your main thread code may never get a timslice in which to join the first thread, until the last thread (20) has waited it's 21+5 seconds.

Unfortunately, the threads API does not support a joinFirst() or joinNextReady() call (think forks and wait) that simply collects the first available dead thread.

You can only join a specified (via thread object) thread. And join will never return ,until that thread ends, regardless of whether there are other dead threads ready to be joined.

This makes using join almost useless, because if a thread hangs, and you attempt to join to it, the joining thread also hangs, which makes a complete mockery of multi-tasking!

I've completely given up trying to make use of the join call, and now detach all my threads, and arrange to return values via other, safely asynchronous means instead.

---

<rant type="personal" target="not the questioner">

This is (another) fundamental flaw in the underlying API upon which Perl's iThreads are modelled.

I seriously doubt if there any sufficiently skilled Perl divers around with enough interest in iThreads to try and fix this, but please, let those designing Parrot's threads be listening and take notice.

</rant>