Actually, it's not. A "thread" is a schedulable unit of execution context. Thereby making kernel threads like Windows threads and pthreads--as used by ithreads--real threads. (The 'real' is redundant.) It also makes some user-space implementations--such as found in Java 1.1, Erlang, and others--that implement their own internal scheduler, also threads. But coroutines are not threads. They are coroutines.
Coro implements its own scheduler. By this definition a "coro" created with Coro's "async" call is a "thread". It contains its own execution context which can be suspended and resumed. I still do not understand why coros created by Coro are not user-space threads in your terminology?
Coro has much more functionality than the classical definition of the coroutine. To implement a coroutine you allow multiple exit points of the coroutine for yielding back to the caller. This is very simple compared to the full functionality of Coro which may be better described as a system of fibers.
The only distinction between coroutines and fibers seem to be that coroutines are built into the language itself and are much simpler. All it takes to implement coroutines is a yield keyword that stops execution, returns a value, and resumes execution after the yield. Coro now seems less like a coroutine because it cannot cede (Coro's yield) any values to its caller. Coro also implements more sophisticated operations than the traditional coroutine. It seems to me more like fibers. More hair splitting... sigh.
Fibers multitask cooperatively. User-level threads use user-level scheduling, which may may very well be cooperative multi-tasking... confusing! GNU Portable Threads (ironic misnomer?) is an example user-level thread library that uses cooperative multi-tasking and switches context instead of I/O blocking. Yes it has threads in its name... argh. This implementation also seems similar to Coro which uses cooperative multi-tasking and yields control instead of blocking on I/O. One difference is that Portable Threads can also schedule its "threads" based on priority.
Are fibers threads? The wikipedia entry starts off with:
In computer science, a fiber is a particularly lightweight thread of execution.
Sheesh... I can see you are adamant in your terminology but my task of translating between everyone's disparate definition of what a "thread" really is, is confusing.
After a quick skim of the abstract confusions, enter the tangible! The fact that perl's ithreads have created a bunch of little pseudo-processes out of the threads! I'm not sure I'm convinced how forward-thinking it is to model processes by using threads. "Real" (OS-level) Processes already must explicitly share data. Processes have private data. Processes run their own interpreter. Process run in parallel. Why reinvent the wheel?
Add in the escher-esque quality of starting an OS process to run perl, which creates a main OS/kernel thread... now perl's ithreads creates more OS/kernel threads which in turn act like separate perl processes. ithreads have their own interpreter, they share data through complex operations akin to IPC which means they are as fast as processes sharing data. This seems more like going backwards than forwards.
This is what Coro's author is apparently talking about in his short description: "Coro - the only real threads in perl". So what is the "real" thread? In my own mind they are both "real" threads with Coro leaning towards a fiber and perl ithreads leaning towards a process.
Your quote on linux threads is a good example of threads in a specific context. Namely the linux operating system and its process model. I was trying to nail down the definition of thread in a wider, abstract context. Namely all of computer science. Just about the only decent source I could find was wikipedia.
The rest of your post about aggregator magic was very interesting!
In reply to Re^7: Why Coro?
by juster
in thread Why Coro?
by xiaoyafeng
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |