I just read RFC from http://dev.perl.org/perl6/rfc/ about thread model in perl.
It's quite old stuff. I hope this still a continuous work. I don't know if you look at Erlang. It's a distributed langage that use cooperative thread. It scale very very well. But Erlang is a slow langage. Thread are a necessary step for performance. When Perl 6 will be out, most of the cpu will be dual core with 2 or 4 virtual cpu per core. So, concurrency are a must to have. On numa system, thread with none shared data are faster, because of cache coherency. So i prefer to have thread local data by default. So the statement "if you add more code, it's slower" work. Thread programming and managing is a pain. The lock/semaphore/mutex approch deliver the fastest code but is the harder to code. There is some other "older" model, that could be much easier to use. It does not scale well, but you don't programm usually a 1024 cpu system. The first one is the barrer. All thread wait when the barrer is reached and start all together. It's often use to parralellised heavy calcul. It's almost like a big lock. It's quite easy to use. The second one is the asynchronous function. A function could be calls with a "async" key word and the fonction return immediately for the current thread (data transmission should be per value to avoid problem, copy on write could be used). When an effective read (FETCH ?) is done on the return value, the thread is blocked until the function is effectively finished. That's a kind of local lock per function. But there is no "lock object". Those model are not as fast as the classical one. But are more easy to use. For the implementation of interpreter, the best will be cooperative thread on top of preemptive thread. Perl programmer see "task", the interpreter do what he want : real thread or not. That's the pool of thread approch. The penalty for perl thread creation will be small. It could be very interresting to have "user" scheduler fonction. This could be usefull in lot of domain. You could provide a default behavior that could be overloded by the user. For performance, you should have one thread per cpu and use asynchronous IO. Then perl interpreter manage this by itself. (if a host OS did not have async io, it could use some more tread) Regards, Nicolas Boulay
