Furthermore, today starting a thread is an enourmous performance penalty, because all non shared data is copied. Unlike forking, where we have copy-on-write (for the curious- it's very efficient, because the kernel simply marks all memory pages as readonly, causing write operations to raise an exception from the MMU, to which the kernel responds to making a new copy of the page which the writing process can work on), there is no optimisation of the process. The main advantage I'm looking for in threads is to gain performance due to concurrency on SMP platforms, for small tasks. Starting a thread needs to be cheap for this to be effective. I think a tradeoff of some continuous speed penalty for an efficient startup time, should at least be a choice.

I'll go looking for some reading material, but I'm sick and too tired to concentrate for any reasonable length of time, so I doubt I can introduce any worthwhile discussion to this thread.

When you use ithreads properly, you create the threads soon, when there are only very few data in the heap, and you use as few shared data as possible. When ithreads is used this way, it should be reasonably fast.

This means that the ithreads model is not ideal for some tasks you could normally do with threads. Ithreads are, however, very good for tasks where the threads do almost independent work, such as fork emulation or servers handling multiple connections. It is not suited for other tasks, such as tasks with heavy paralel computation imo.

Thus, I aggree with your original post in that ithreads might not always be what you want.

I do not know about any high level language supporting a thread model similar to for example pthreads, probably because that would make the interpreter unstable when you do not uses locks properly (5005Threads were like that iirc). If you need such threads, you migt want to look at other languages than Perl. Ruby has continuation-based threads, that means of course that it uses only one cpu at a time.