Re: Power patch to support flexible lua_writestring

[bil til <biltil52@...>]

>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).

Am Fr., 24. Feb. 2023 um 06:19 Uhr schrieb William Ahern
<william@25thandclement.com>:
>
> On Sat, Feb 18, 2023 at 05:48:41PM -0800, Nathan Page wrote:
> > Hi All,
> >
> > I've made a patch to lua that I thought may come in handy for embedded
> > use cases. It essentially adds a lua_State argument to
> >
> > - lua_writestring
> > - lua_writestringerror
> > - lua_writeline
> >
> > and subsequently modifies all occurrences of the api in the source
> > code to add the state. For a standard lua installation this doesn't
> > change anything. Now the writestring methods could access lua state to
> > make more flexible output handling.
>
> 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.
>
> lua_writestringerror is used only used by 1) the default panic and warning
> handlers, 2) the iteractive debugger, and 3) some command-line interpreter
> option argument handlers. #3 can't be reached in an embedded scenario. For
> #2 even if you wanted an interactive debugger in an embedded context, the
> entire routine, db_debug in ldblib.c, is only 13 lines of C code, and it's
> only accessible as the global debug.debug in Lua script; it can be trivially
> replaced with your own implementation.
>
> lua_writestring is only used by 1) the global function 'print' and 2) the
> interpreter for the -V option flag. In both cases printing to stdout is the
> intended behavior.
>
> Importantly, in a context where a process has multiple Lua VM contexts you
> almost certainly want to install your own panic handler regardless of where
> messages are printed, because if the panic handler returns then Lua calls
> abort(). (See luaD_throw in ldo.c.)