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

Guys,

IMHO a non-preemptible thread and a coroutine (at least the kind of coroutines you are talking about, which have a private stack) are the same thing.

When such a thread yields, it saves (usually in its stack) the context it needs for resuming. The stack pointer must be saved somewhere else. The context depends on the language implementation; in a typical compiled language it may include some machine registers if they hold variables. This is the same context that any standard function must save when calling another function.

In the case of a preemptible thread, control may be taken away from the thread as the result of an interrupt. This context switching works the same as a yield (save context in current stack -> switch stack -> recover context from new stack), but the context is bigger, since it is the context saved by an interrupt, and by definition an interrupt must save and restore everything necessary in order to leave no trace of its execution. The context saved by an interrupt usually includes all machine registers and maybe other stuff like some IO device registers, memory mapping, segment tables, etc. etc. The exact contents depend basically on the hardware and the OS, not the language implementation, and it is a superset of what a thread must save and restore when yielding.

Am I missing something?

Hugo Etchegoyen

David Kastrup escribió: [Adrien de Croy <adrien@qbik.com> writes:

David Kastrup wrote:
 

Adrien de Croy <adrien@qbik.com> writes:
 
 

I agree
in the context of OS threads, it refers to an independent call stack
and context.
 
 

What do you mean with context?
 

in an OS thread, the context includes things like CPU registers etc.
 

Coroutines just save those things that a function call saves.
 

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

Uh what? A thread that is neither preempted nor yields is not a
thread.
 
 

a thread is a simple object. A scheduler pre-empts threads, the
thread does not pre-empt itself.
 

Straw man. "being pre-empted" and "is neither preempted nor..." don't
talk about threads preempting themselves. So you are defeating a
point that has never been proposed.
 

where did I say that a thread that is neither pre-empted NOR yields
is not a thread? those are your words not mine.
 

Yes. Your point was?
 

My words were "independent concepts". That does not imply mutual
exclusivity, merely independence. Things can be independent without
having to be mutually exclusive.
 

But they aren't independent. That was my whole point. I _understand_
what you are saying perfectly well. And it is wrong.
 

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

I don't see an "own context" in any sensible meaning of the word,
and of course coroutines all have their own stack. That's the
whole point of them. The difference between coroutines and threads
is that coroutines have a single flow of control. That means that
there is no necessity for any locking in coroutines. The sequence
of operations is uniquely determined by yielding. That is no
different to subroutine calls, _except_ that yielding does not
leave the call stack of the current coroutine and reenters at the
same place.
Essentially wrapping a function body into one endless loop with a
yield at the end is pretty much the same from a transfer of control
view than returning.
 

Actually the issue I was attempting to address was the question
raised about whether it was correct to call a lua thread a thread at
all. I believe it has the requirements to be validly called a
thread.
 

And I don't believe so. It is a coroutine. _If_ one distinguishes
the concepts of coroutines and threads, then Lua threads _clearly_
belong in the former category.