 |
lua-l archive |
|
|
||
|
David Kastrup wrote:
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.
I believe a thread can exist outside having to be pre-empted or yielding. That makes it independent of pre-emption / yielding.
You yourself mention another possibility in another email - in multi-CPU machines where a thread could conceivably be neither pre-empted nor yield, but simply keep running.
I don't know if the whole body of computer science would wish to submit to your edict that a thread shall not exist independently of the concept of pre-emption / yielding, I'm prepared to consider there may be other options. That's probably why we use different phrases/words to describe the concepts. because they are different.
OK, I'm not familiar with the term "coroutine" enough to argue that point. It doesn't appear in any documentation I've read except for Lua. 16 bit Windows and MacOS used cooperative multitasking, but I never saw the term "coroutine" mentioned.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.
I'd also query how any subsystem that runs on a pre-empted OS can guarantee serialization of calls to a coroutine subsystem without binding to a single CPU and running only in a single OS thread (or using OS lock primitives).
Regards Adrien -- Adrien de Croy - WinGate Proxy Server - http://www.wingate.com