Yes. That would be a perfect description of Coro's coroutines. Though "coroutines" is better, if for no other reason than it is a term that isn't associated with MS, as fibres (wrongly) are. It's also an older and very well understood term in CS circles.

But I think that is to ignore the political aspect of the Coro pod. Anyone who includes vitriol like this in a module's documentation, is obviously too far gone for rationality.

A great many people seem to be confused about ithreads (for example, Chip Salzenberg called me unintelligent, incapable, stupid and gullible, while in the same mail making rather confused statements about perl ithreads (for example, that memory or files would be shared), showing his lack of understanding of this area - if it is hard to understand for Chip, it is probably not obvious to everybody).

Especially as what Chip Salzenberg said is correct. At least as far as memory and file handles are concerned; they are shared within a single process space. Access is controlled and limited only at the language level; not the kernel or processor level. As for his remarks about the author, I don't know him so I couldn't make comment; but I suspect that anyone with even a cursory understanding of ithreads has long since drawn their own conclusions.

The only lack of understanding regarding ithreads is clearly demonstrated by the author. Though I suspect his "confusion" is, at least in part, political rather than genuine.

Anyone who includes vitriol like this in a module's documentation, is obviously too far gone for rationality

For what it's worth, I found the author to be very much available and helpful for newbie Coro questions on IRC.

Marc Lehmann is in fact spot on and Chip is incorrect. There's no "politics" involved here. At least not on Marc's side.

Perl's "threads" are not threads in the generally accepted term, yes wikipedia does say "In computer science, a thread of execution is the smallest unit of processing that can be scheduled by an operating system."

But it also goes on to say

", but in most cases, a thread is contained inside a process."

Perl's implementation of "threads" is actually done using forking and there is *no* shared memory space. You're getting confused as what actually happens is *ALL* the data from the main process is copied across to the memory space of the "threads". They are processes and have their own memory space. Real threads execute inside the 1 process and share memory.

For interpreted languages there is what's called a GIL(Global Interpreter Lock) which is there to prevent non-thread safe code being shared with other kernel threads. Ruby and Python have a GIL and their threads are known as 'green threads' which are not kernel level but are after the GIL, but still share memory. They of course will not take advantage of multi-cores. On a side note you can get real kernel level threads with both Ruby and Python through jRuby and jPython, but nothing like that exists for Perl.

Perl's psuedo-threads will take advantage of multiple-cores because they are processes and they do NOT share memory. Marc knows his stuff. He wouldn't have been able to write Ev, AnyEvent, Coro to be as stable and fast as they are if he was lacking in such basic knowledge that even *I* know and I consider myself intermediate at best.

But, please don't take my word for it. Check perlthrtut. First paragraph.

"This tutorial describes the use of Perl interpreter threads (sometimes referred to as ithreads) that was first introduced in Perl 5.6.0. In this model, each thread runs in its own Perl interpreter, and any data sharing between threads must be explicit. The user-level interface for ithreads uses the threads class."

Notice the word 'explicit'. That means you have to, yourself share any data between 'threads'. This is the very purpose of threads::shared. Why would that module exist if Perl 'threads' shared memory as Chip Salzenberg and yourself claim?