Threading is an interesting subject. This is what I have learned from peeking at the source code (I think it was perl version 5.12). I also think BrowserUk's treatment is a little harsh but he most likely has good reason to be if he had to program windows before it was pre-emptive :).
Perl does use kernel threads (ie pthreads, Win32 threads). The code is located at dist/threads.xs inside the perl source tarball. The confusing part is it uses threads to model processes. This is not so confusing when you consider the source of the new perl threads being for fork() emulation on windows. Interestingly, python does use actual lightweight kernel threads for it's green threads. Yet only one thread runs at a time, like you say with the GIL.
So when Mark Lehmann says his Coro module are the "only real threads" and that perl's threads aren't real threads. Well... defining what a real thread is kind of confusing. Perl threads are "real" kernel threads. In my limited experience they perform like processes and give about the same performance as perl's fork() or python's "multiprocessing" module (which uses python's internal fork()).
The wikipedia entry mentions the user-level model of threading ("N:1" under "Models") so does this means that Coro's coroutines are indeed threads? They just happen to be user-level threads. Coro's "threads" perform closely to Python or Ruby's "threads" (which are also coroutines, user-level threads).
I think Coro is really neat and think it's mainly useful when you need to model your program asynchronously with many little workers who share a large amount of data. Perl threads are also really neat when you don't have to share a great deal of data. I think most of the frustration is in poor use of terminology. They are both threads... just different types.
In reply to Re^5: Why Coro?
by juster
in thread Why Coro?
by xiaoyafeng
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |