|
Creating a solution with setjmp/longjmp was not too hard (code:
see below).
But I wonder, what could it really break?
It seems it does not leave a memory leak after lua_close (tested with clang address sanitizer), I suppose all user defined garbage collecting functions are called as well.
For a C library function using lua_pcall or lua_yield, I do not violate any valid expectation. A Lua library function calling lua_pcall cannot be sure the lua_pcall function will return, since the Lua code could also switch to another coroutine. For lua_yield, it is even stated in the manual “only use as a tail call”. Unless I have some unknown error in this reasoning, I do not introduce any additional problem.
For a C library using lua_pcallk or lua_yieldk, I was not sure at first – but I found there is no guarantee that a continuation function will ever be called. So, this should not cause any new problem as well.
Did I miss something?
On Thu, Feb 25, 2021 at 9:58 PM bel <bel2125@gmail.com> wrote:
> Is there some recommended method to do this?
Unless you control tightly all the "C" [1] code, including all the
libraries, that interacts with a given state, that is generally
impossible. Because "C" code will generally expect that no transfer of
control can happen across lua_pcall (and the like) boundaries.
Whatever you do, you will either have to violate the expectation, with
generally unpredictable consequences, or have to be limited by it.
[1] "C" meaning whatever uses the Lua "C" API, which is not
necessarily in the C language.
Cheers,
V.