Re: LuaJIT vs C++

["Alexander Gladysh" <agladysh@...>]

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

Am I safe if I do not call *any* Lua functions inside that try/catch?

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

WOW! That is great, thank you!

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

Does that count loadstring() calls with code which does not create any
functions? Eg "return { "data" }". Even this should not be a problem
for us though.

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

Thank you again, I'm going to test it right now :-)

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

Hmm... Whatever mehod MSVC 8 uses as default. I *guess* we're flexible
enough here. Sorry, I would be able to get my hands on Windows build
to check only on Monday.

Alexander.