Re: interrupting coroutines (was Re: Local Variables)

[Patrick Donnelly <batrick@...>]

On Tue, Aug 12, 2014 at 2:40 PM, Roberto Ierusalimschy
<roberto@inf.puc-rio.br> wrote:
>> > What is "gL" here?
>>
>>   lua_State *gL;
>>
>>   It's a C variable that is either global, or static to the file the
>> routines are defined in.
>
> And where its value come from? (I thought the whole point of the
> discussion was how to access the *running* coroutine when a signal
> happens.)

I think it's fruitful to summarize the problems with interrupting Lua
(coroutines):

* You cannot safely, asynchronously interact with Lua. Even
lua_sethook is undesirable if you're using multiple Lua states.
* You cannot find the main thread to set a hook on.
* Hooks do not/cannot propagate errors to the root pcall (whoever is
working on the main thread).

It seems to me the answer for solving this, if it should be solved, is
to take the same approach most C programs do: set a static variable
indicating a signal has been received and check it synchronously in
the main program.

For Lua, this would mean providing an API to add a pointer to this
static variable to the global state which is checked on each byte code
instruction and other major lua_ entry points. There would also be a
global state lua_Hook just for interrupts which is run in the "current
thread" (which would just be whatever thread is currently being
interacted with since C code doesn't *have* to use Lua's lua_resume
interface to run code in a thread).

As for the third problem, propagating the error to the root pcall,
perhaps the interrupt handler could leave the flag set and allow Lua
to recall the interrupt hook which throws errors until the root pcall
is reached.

-- 
Patrick Donnelly