Re: LuaJIT vs C++

[Mike Pall <mikelu-0803@...>]

Alexander Gladysh wrote:
> >  > As you know, compiling Lua as C++ basically changes longjmp() in
> >  > LUAI_THROW to throw; and setjmp() in LUAI_TRY to try {} catch() {}.
> >  > This change is crucial as longjmp/setjmp basically do not call any
> >  > destructors in C++ objects.
> >
> >  That's only part of the problem. The other issue is that throwing
> >  a C++ error "across" a C++ -> Lua -> C++ call chain would leave
> >  Lua in an inconsistent state.
> 
> Hmm. I naively thought that that try/catch in LUAI_TRY deals with that issue.

Yes, it does. I just wanted to point out that there are two
issues which need to be solved:
1. Cleaning up C++ frames if a lua_error() is thrown.
2. Cleaning up the Lua state if a C++ exception is thrown.

> >  Well, this is a matter of resources for me, too. I've already
> >  researched how to pass the necessary info to the GCC unwinder at
> >  runtime. Unfortunately, this is quite complicated and would take
> >  a lot of time to implement. I'm not sure it's worth the effort to
> >  add this to the LuaJIT 1.x branch.
> 
> I see. Am I correct that the only feasible option for us at the moment
> is to compile LuaJIT as plain C and to rewrite all our bindings as
> follows:
>
> [... try/catch inside the binding ...]

Well, this solves issue 2, but not issue 1. Most Lua API
functions can throw a lua_error() (e.g. luaL_check*) and then
your C++ frames are not cleaned up. You would need to be very
careful to avoid RAII anywhere a Lua API function may be called.
I guess this renders this approach unfeasible.


But in other news: I've made a quick fix for LuaJIT 1.1.4. Now
all JIT frames have constant stack space usage. This means they
are slightly larger. You probably won't ever notice unless you're
using recursion heavily. This simplifies DWARF2 frame unwind info
generation.

I still consider this a hack because it adds a CIE+FDE for every
JIT-compiled function. Seems a bit excessive -- one per memory
area would suffice. And it currently leaks one unwind base object
for every compiled function (non-issue, except if you use
loadstring() a lot).

Anyway, I've sent this experimental version to you by mail. Let
me know how this works out for you.

Which exception handling method are you planning to use with
Windows? There are few to choose from, depending on the compiler.

--Mike