lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]


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

I did not have time yet to look into the details again... I did this
ca. 2 months ago and do not remember the exact details, but this "lost
Lua state" was the main problem, why I also just decided to
"short-circuit" the complete current Lua warning handling and defined
my own way to handle it (by just using my own warn function...).

If I print anything through e. g. "relatively slow RS232 interface" in
my embedded STM32, then it is clear that I can do this only INSIDE a
resumed Lua thread (if you try to call yieldk from a non-resumed Lua
state, Lua immediately will panic into "try yield from unresumed
thread" or similar error). If I find more time to check this again, I
will report in the next 1-2 weeks... . (i solved it otherwise
meanwhile and I am happy so far...).