Re: What's the difference between a "coroutine" and a "thread" in Lua?

[Adrien de Croy <adrien@...>]

I agree

in the context of OS threads, it refers to an independent call stack and 
context.  Process memory is shared and accessible to all threads of a 
process.  Stack variables however, belong to the thread whose stack they 
reside in.

re-entrable code vs yielding or being pre-empted are independent 
concepts to that of a thread.

Since a lua thread provices another call stack, and has its own context, 
I think it qualifies to be called a thread.

Jerome Vuarand wrote:
> Gregg Reynolds wrote:
>   
> > If it were clear, questions like "what's the difference between
> > threads and coroutines" would never arise.  The text may work for
> > you, but it's utterly misleading for me.  First, I can only know that
> > Lua uses an idiosyntractic meaning for "thread" if I happen to have
> > read and understood the other relevant sections of the manual.  Even
> > worse, the second sentence of 2.11 states:  "A coroutine in Lua
> > represents an independent thread of execution. "  Some may consider
> > that clear, but it's clear as mud to me, because "independent thread"
> > strongly implies to me that we're talking about multithreading
> > (whether implemented in         
> > kernel or user space).   (Even worse worse, look at the definition of
> > the type thread, which could not possibly be more obscure.)  In my
> > view Lua coroutines are by definition _not_ independent, since they
> > must cooperate.  It would be more accurate if not more clear to a)
> > remove all reference to threads, and b) call them distinct,
> > sequestered,  or the like, but not "independent".  Why not just use a
> > standard definition of coroutine?  E.g.  a coroutine is a subroutine
> > that supports suspend/resume operations and multiple entry points. 
> > It has nothing to do with threads, unless you're willing to say that
> > every routine (function) is a thread.  You could stipulate that every
> > jump represents a jump to a different "thread" but that seems kind of
> > pointless.          
> >     
>
> I think you are confusing multithreading and preemptive multithreading.
> Cooperative multithreading is a kind of multithreading. Any chunk of
> code (function, subroutine, procedure, whatever...) that can be
> interrupted, be it preemptively by the kernel or cooperatively by the
> chunk itself, and later resumed is an independant thread (you doesn't
> need anything but the thread itself to resume it).
>   

--
Adrien de Croy - WinGate Proxy Server - http://www.wingate.com