[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Monotone-devel] 3rd party libraries

From: Matthew Nicholson
Subject: Re: [Monotone-devel] 3rd party libraries
Date: Sun, 26 Oct 2008 22:04:26 -0500
User-agent: Mozilla-Thunderbird (X11/20081018)

Stephen Leake wrote:
Matthew Nicholson <address@hidden> writes:

Zack Weinberg wrote:
On Thu, Oct 23, 2008 at 3:38 AM, Markus Wanner <address@hidden> wrote:

 * lua: pretty similar to sqlite, except the source inclusion variant is
a bit more complicated. I'm all for dynamic linking and don't see much
of a reason for source inclusion.
I think I mentioned this before, but if we're going to stop bundling
lua we have to overhaul the error-handling interface between lua and
our code, because we're currently relying on lua's ability to be
compiled as C++ and use C++ exceptions to report errors.  Of course we
need to overhaul it *anyway* because right now lots of errors just
silently get lost, but remember that this is on the critical path for
unbundling it.
Yeah, I recently noticed the same issue.  To properly unwind the stack
on error in a c++ app, lua needs to be compiled with a c++ compiler.
It uses setjmp and longjmp for error handling when compiled as C and
exceptions when compiled as C++.  If we don't require stack unwinding
on error (I have not looked at the code), then dynamic linking is
fine, but I think this is a candidate for bundling.

I'm confused.

You seem to be implying that a dynamically linked object file cannot
be compiled with a C++ compiler. Is that correct?

Or is there some limitation on dynamically linked object files, that
says they can't propagate exceptions?

It has nothing to do with linking really. It's all about how lua signals errors. If there is an error in some lua code, or c++ or c code called from a lua function, that error is handled at the location of the nearest lua_pcall() usually. If compiled as C code, lua jumps to that location using setjmp and longjmp, c++ exceptions are used if compiled as c++. This is a special c++ exception that is caught by lua (not by the host application). When using set/longjmp the stack is not unwound, so no c++ destructors are called. This can cause memory and other resource leaks.

So this was not completely clear from the other responses. To help visualize this, draw an imaginary line between lua code and c++ code called from lua and monotone's other c++ code. Errors (C++ exceptions) are not supposed to cross this line. Basically the way to signal errors from lua code is by calling the lua_error() function (or just error() from lua code or luaL_error()). This will cause lua_pcall() to return the error to the host application. I'm not sure if throwing a c++ exception from lua code will cause any problems or not.

If we are very careful and make sure all clean up is done in the event of a lua error then there are no problems using the C version of lua but this is generally difficult to do.

Matthew Nicholson

reply via email to

[Prev in Thread] Current Thread [Next in Thread]