I've read this post far more times than I care to admit and I still see no merit to conflating "threads" and "coroutines".
To me, the salient feature of coroutines is the ability to start from the beginning or from where we left off, while the salient feature of threads is independent simultaneous execution with (possible) data sharing. These are separate "primitive" concepts in my brain and merging them into one cothread thing just seems wrong.
I think you are right, and that your post (unintentionally) demonstrates the merrit of what Michael was saying.
The "salient" features that you mention are the ways in which they differ -- and thus the reason not to merge the two into a single entity. But there are many things that are common, such as the need to manage multiple stacks, and the need to communicate values between peers. Are the following snippets really more different than they are alike:
for < thread { sleep 1 and yield $a++ while 1 } > { print }
for < coro { sleep 1 and yield $a++ while 1 } > { print }You could argue that using C<yield> to send a message from a thread is incorrect. Indeed, we could use a different keyword there. But to do so is to miss the similarity in the intent.
my $tid_child = thread -> $tid_parent { do_stuff }
my $cid_child = coro -> $cid_parent { do_stuff }These cases are perhaps less similar than they appear. Each creates a new context for executing a code block, and each provides handles for communication between the parent and the child. We might use the tid/cid handles to setup communication channels between the two contexts. In the case of the thead, a communication channel would probably require a fifo; whilst for the coroutines, communication is intimately tied to the control flow.
With coroutines, locking is probably not necessary (though in complex situations, locks can be used as assertions). With threads, locks are probably necessary. But a lock manager is associated with the schedulers, not the threads/coroutines themselves.
My summary is that yes, coroutines and threads are very different things. But most of the language-infrastructure needed to support one, is also needed for the other.
Dave.
