[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: What's the difference between a "coroutine" and a "thread" in Lua?
- From: David Kastrup <dak@...>
- Date: Mon, 13 Aug 2007 13:39:43 +0200
Adrien de Croy <email@example.com> writes:
> David Kastrup wrote:
>> Adrien de Croy <firstname.lastname@example.org> 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
> 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
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.