Re: Power patch to support flexible lua_writestring

[William Ahern <william@...>]

On Fri, Feb 24, 2023 at 09:25:19AM +0100, bil til wrote:
> >For Lua 5.4 none of this should be necessary if you use lua_atpanic and
> >lua_setwarnf. Both already take a context argument--a lua_State for the
> >panic handler, and an opaque context for the warning handler.
> 
> ... but this context argument / lua_State is "static" - you have to
> specify this at the time when you invoke lua_atpanic and lua_setwarnf.
> 
> If you work with coroutines, or yieldk/resume, you need the lua_State
> of the "currently panic Lua thread" (the thread which is running
> inside resume) ... otherwise you would immediately run into the next
> "panic", if you try e. g. to print something from a "non-resumed" lua
> thread (especially if your print itself invokes yieldk again, which is
> quite normal in embedded systems, as such communication functions like
> print ARE very slow... need wait times / sleep times).

The panic handler receives the lua_State that panic'd. And in any event, the
posted patch passes the same lua_State to the modifed lua_writestringerror
that would be passed to the panic handler; nothing changes by using
lua_atpanic, except now you can control whether and where your program
aborts.

For the warning handler you do lose access to the running lua_State. But why
would you need the *running* lua_State to print an error message? As opposed
to the main lua_State or specially prepared state(s) for running diagnostic
or recovery code? (I could imagine reasons, but anything worthy of breaking
the API?) Note that even with the patch you still couldn't yield from the
warning handler (nor the panic handler, for that matter) because the calling
code isn't prepared for that.

Also, with the patch the lua_writestringerror handler doesn't actually know
whether it's being called from a panic handler or a warning handler--quickly
reading luaD_throw and luaE_resetthread, it looks like lua_state should
return LUA_OK within the panic handler (untested, though).