Re: Can't interrupt tight loops in Lua 5.4 anymore?

["Joseph C. Sible" <josephcsible@...>]

On Mon, May 18, 2020 at 3:53 PM Roberto Ierusalimschy
<roberto@inf.puc-rio.br> wrote:
>
> > There is a third case: threads.
>
> As far as I know _pure Lua_ does not have threads. But anyway...
>
>
> > Does this apply to the case when lua_sethook() is called asynchronously,
> > after the loop execution begins?
>
> Yes, for a reasonable definition of "asynchronously". But note that,
> if you are using the standard GIL in Lua code (which is the only
> reasonable definition of "asynchronously" I can think of), a tight loop
> can never release the lock, and so the other thread will never run.
> When/if the thread runs and sets a hook, it will be called.
>
> The only issue is with real signals, which can set a hook at fully
> arbitrary points inside the interpreter. If the hook is set at
> some very specific points during the manipulation of CallInfos,
> maybe Lua can lose it. ("maybe can" means we do not guarantee it
> will not happen. It doesn't imply it can happen.)
>
> -- Roberto

Under the assumption that function pointers are atomic, perhaps
there's a way to fix the CallInfo race, the Undefined Behavior with C
threads, and being unable to stop a coroutine, all at once: add the
concept of a "global hook". Here's how I think it could work:

* Create a new function called "lua_noophook" that just returns
without doing anything.
* Add a single "volatile" function pointer to global_State called
"globalhook", that points to lua_noophook by default.
* Everywhere that we check to run hooks now, also unconditionally call
the "G(L)->globalhook" function pointer, as if it were a LUA_MASKCOUNT
hook with a count of 1.

I think that would have the desired semantics in almost every case
today that currently sets a hook asynchronously. (And in the uncommon
case of wanting to do something else, you could do it from the global
hook, and then reset it back to lua_noophook.)

Does this seem like a good solution?

Joseph C. Sible