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

[David Kastrup <dak@...>]

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.

-- 
David Kastrup