|
As we know it's possible to use lua_resume() with lua_sethook() to get
cooperative timeslicing of sorts for a Lua thread, and even implement multiple
threads with a Lua script. Of course it's not particularly efficient, and the
execution of the global state can't be timesliced in this way.
Having an explicit mechanism for cooperative timeslicing of the VM without
the overhead of the debug hook, and for all cases of execution, would be very
useful. This might be achieved by pcall/resume functions that set an internal
flag to enable a polled mode for the VM, e.g. lua_ppcall(), lua_presume() etc..
These would then return immediately after having prepared the Lua state for
polled execution, and then there might be a function to drive the VM execution a
few instructions at a time by polling. So something like:
int status = lua_ppcall( L, ... );
while( status == LUA_CONTINUE )
{
status = lua_pollvm( L, number_of_instructions );
}
Such a cooperative timeslicing method would allow any number of Lua
scripts/threads to run within a single host thread, allowing easy and
inexpensive multithreading, synchronisation, aborting or timing out scripts
etc.. Library functions called from Lua would still block of course, unlike when
running a Lua state in a dedicated preemptive thread, but that might be
acceptable. It could hopefully be quite efficient and easy to implement and
could open up for new ways of using Lua. Any thoughts?
|