Re: LuaJIT, ObjectiveC, @throw in lua_atpanic, clang, infinite recursion

  • From: Konstantin Osipov <kostja@xxxxxxxxxxxxx>
  • To: luajit@xxxxxxxxxxxxx
  • Date: Tue, 26 Jun 2012 13:56:47 +0400

Hello Mike,

Thank you for your reply.

* Mike Pall <mike-1206@xxxxxxxxxx> [12/06/24 13:18]:

> Umm, an atpanic handler is only a last resort. The Lua state is
> non-recoverable after it gets called. The only thing you're
> allowed to do inside of it is to print something and then exit().

Is there any other way to ensure that lua_error() throws an
instance of our application exception class?

> So always wrap your code in lua_pcall(). In fact, in LuaJIT it has
> the same cost as a lua_call(), so there's no reason not to use it.

Up to now we relied (maybe not in a fully correct way)
on LuaJIT exception interoperability documented at 
http://luajit.org/extensions.html

Do you advise against it in our case?

> > Being able to propagate exceptions through LuaJIT stack is a nice
> > feature of LuaJIT and we use it quite extensively.
> This only works with full exception interoperability (i.e. x64)
> and only if all components use the same native exception handling
> model.

Right, so I'm exactly looking for ways to achieve this
interoperability when compiling with clang on Linux and/or when
compiling with gcc on Mac OS X. These are the only two cases
when we've failed to come up with correct build options yet.

Why this is important to us:

We use Lua to implement database stored procedures. 

A program in Lua invokes C/Objective C callbacks which
put/get data from the database.

These callbacks, in case of an error, throw exceptions,
(that's how our database software is written).

The reason we're not using pcall to invoke Lua programs
is that pcall catches these C++/ObjectiveC exceptions
thrown by callbacks, and we'd like them instead to pass directly
to the invoker of the procedure.

Similarly, we'd like to convert any Lua error to an exception,
and also pass it back from the lua_call as an exception.

If we use pcall, then, to achieve the same effect, 
we'll have to wrap any call to C code with LUAJIT_MODE_WRAPCFUNC,
and convert exceptions to Lua errors when they occur.

Then we'll have to convert Lua pcall results to an exception
again. 

In other words, it is a double conversion just to ship the
exception through LuaJIT layer.

This conversion is undesirable both due to its performance
overhead and implementation cumbersomeness.

So far we were willing to take the trouble of making
sure both stacks are interoperable and exceptions can
pass through LuaJIT unharmed.

It works well (with a few compile tricks), when compiling with gcc
on FreeBSD and Linux, both 32 bit and 64 bit.

The most recent trouble arose when we began our port to Mac OS X,
where we were unable to make our tests pass, regardless of whether
we compile with clang or gcc.

It must be soluble there as well, at least when compiling with
gcc, is it not?

> That's not too surprising. ObjC exception handling changed from
> setjmp/longjmp-style to native exceptions some time ago. Not all
> distros have made the switch. Have a look at the GCC man pages for
> -fobjc-exceptions and the caveats about interoperability with
> (native) C++ exceptions. It's basically a big mess when it comes
> to cross-platform portability.

Starting from gcc 4.6, gcc uses the same style for Objective C and
C++ exceptions. This was necessary to fix Objective C++
C++/Objective C interoperability. So I think this part is solved.

-- 
http://tarantool.org - an efficient, extensible in-memory data store

Other related posts:

  1. Home
  2. luajit
  3. Archive
  4. 06-2012