Re: running the Lua VM "in time slices"

[Jens Alfke <jens@...>]

On 30 Dec '05, at 8:51 AM, Dolan, Ryanne Thomas (UMR-Student) wrote:

okay, well I found two problems with this approach already:

"Say you have a scheduler, which starts up various threads. One of these threads, call it T, decides to create a coroutine as a generator (G).  So the parent of T is the scheduler; if T yields, it returns to the scheduler.  But the parent of G is T; when G yields, it returns its result to T. If a yielding hook is active while G is running, it will yield to T, not to the scheduler. That would probably be disastruous, which is why I think that yielding hooks are incompatible with the use of coroutines."  -RLake

And in general, one can't take a program written using cooperative threading (which is what Lua coroutines are a form of), drop in an interrupt-driven scheduler, and expect the program to continue working. If threads are interrupted at times they don't expect, their expectations about exclusive access don't hold anymore. For example, a shared variable might be altered by another thread while a thread was interrupted, but it didn't expect this because it hadn't explicitly called yield().

I think the idea of a hook called every N instructions can be used to solve the original problem, but the hook has to be at the C level and can only run native code (i.e. the PalmOS event handling stuff), not Lua. Or rather, if it invokes the Lua VM, it has to be very careful to avoid stepping on any shared state. The most it could do, probably, is to push an event object into a queue somewhere.

(Oog, now I'm having flashbacks to when we ported the Mac Java runtime to OS X and had to deal with crazy threading issues with the Carbon libraries...)

--Jens