RE: running the Lua VM "in time slices"

["Dolan, Ryanne Thomas (UMR-Student)" <rtdmr6@...>]

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 also yielding hooks requires that the current hook be changed.  I guess it would be possible to store the old hook and set it again later, but this will produce unexpected results from the perspective of anyone else setting a hook.
 
I really think a mechanism for preempting a thread after a certain time would be very useful and would allow non-cooperative concurrency.

________________________________

From: lua-bounces@bazar2.conectiva.com.br on behalf of Dolan, Ryanne Thomas (UMR-Student)
Sent: Fri 12/30/2005 9:55 AM
To: Lua list
Subject: RE: running the Lua VM "in time slices"


No problem there.  I think you can just remove the initial lua_pcall in the C code and it should always work as expected.
 
It's funny, but I came up with this same solution last night before I fell asleep.  The idea is just to call lua_yield in a hook that runs after a while, and replace lua_pcall with lua_resume.
 
What's really cool is that you can write a Lua module to do this from Lua scripts.  You could even extend the coroutine library as follows:
 
f = function ()
    while counter < 100000 do
        counter = counter + 1
    end;
end;
 
t = coroutine.create (f);
 
while coroutine.resume_for_given_instructions (f, 100) do
    print ("coroutine t preempted!");
end;
 
This approach still uses coroutines but doesn't require explicit yields within each thread.  Instead, the currently running thread gets preempted by the hook.
 
The new resume_for_given_instructions function is easily written using only the Lua C API.  For this reason, I would suggest including it (with a better name) in the next release of the standard library.  It would simply register a hook which calls lua_yield and then call lua_resume.  It allows scripts that weren't written as coroutines (ie with yields) to be run as coroutines.  This would at least evaporate my disdain for the coroutine library.
 

________________________________

From: lua-bounces@bazar2.conectiva.com.br on behalf of Gerhard Sittig
Sent: Fri 12/30/2005 7:39 AM
To: Lua list
Subject: Re: running the Lua VM "in time slices"



On Thu, Dec 29, 2005 at 23:05 -0800, David Andersen wrote:
>
> You want to do this I think:
>
> http://www.icynorth.com/forums/viewtopic.php?p=228&sid=24c427141b80232a86258d2e41c6b0ee#228

Thank you for the pointer.  Haven't thought of such an approach yet.  I
could start some Lua glue of my own from the C application and have this
Lua glue run another user provided Lua chunk with periodic callbacks.


I took the code snippet and it works as advertised.  But then I tried to
make sure that even the initial pcall (where the loop() routine gets
declared) runs with debug hooks set.  Because nobody could stop users
providing a script like this:

  -- the loop() declaration has been there before
  counter = 0

  function loop()
      while counter < 10000 do
          counter = counter + 1
      end
  end

  -- this immediate calling loop() is new
  loop

Doing luaL_loadfile(), i.e. compiling the source, is no problem.  But
running this code the first time to declare the counter variable and the
loop() routine (as the message you refer to does) may already block in a
possibly infinite loop.  Remember, I won't have any influence on the
scripts the VM is fed with.  Neither can I (hard) require users to
provide an entry point like a main() routine or something.  I want the
thing to look as much Lua as possible.

Will have to look a little more into how to even "supervise" the first
invocation.  Maybe wrapping the Lua user code in my own Lua glue will be
the solution.


virtually yours
Gerhard Sittig
--
     If you don't understand or are scared by any of the above
             ask your parents or an adult to help you.

<<winmail.dat>>