[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: is it possible to make longjmp-free Lua?
- From: Mark Hamburg <mark@...>
- Date: Mon, 27 Jul 2009 08:09:17 -0700
On Jul 27, 2009, at 4:47 AM, Juris Kalnins wrote:
On Mon, 27 Jul 2009 12:55:23 +0300, Juris Kalnins <firstname.lastname@example.org> wrote:
Lua error mechanism only require setjmp/longjmp, not C++ exceptions.
Are you sure -fexceptions is needed for setjmp/longjmp to work ?
-fexceptions generate data needed for destructors to be called,
setjmp/longjmp and thus Lua error mechanism do not need.
But c++ does need it. It runs destructors on function exit. You
cannot simply discard stack frames in C++. (And see above example
for why it is bad for C, too).
Sorry, this reply was unnecessarily terse. To clarify: problem is
not that setjmp doesn't work with -fno-exceptions, but that C++
throw/catch cannot be used with -fno-exceptions, and thus any Lua
exception that unwinds C++ stack frame is an error. In other words,
it is not possible to call most of Lua API from C++ functions that
have non-trivial local variables, if Lua doesn't use C++ throw for
You can address that by only using lua_pcall to call from C++ to Lua
and being prepared for any errors that come back. Or you could if you
didn't have to also worry about all of the memory and parameter errors
that will then necessitate going though lua_cpcall. And unfortunately,
lua_cpcall is moderately expensive since it needs to build a new
This brings up an old thought I had when I last looked at trying to
bottleneck things through lua_cpcall: Would it be useful to have a
light C function data type that would have no environment or upvalues
and which could be stored in a TVALUE without allocating storage?