On 03/04/2013 10:08, Holger Joukl wrote:
Hi Giuseppe,

thanks for answering and sorry for the delayed response. Easter
holidays :-)

To punish you here's another late reply.

Giuseppe Corbelli<giuseppe.corbe...@copanitalia.com>  wrote on 28.03.2013
09:37:39:

On 26/03/2013 18:51, Holger Joukl wrote:

Hi,

I'm wrapping a C++ library that's actually just a thin wrapper around a
C lib.

Through a dispatch() method of a Dispatcher class there's an invocation of
callbacks which get implemented on the Python side, by subclassing
callback classes exposed through Boost.Python.

Now, for performing the actual dispatch the C++ library calls into the
underlying C library.

This hasn't been a problem so far as we've been targetting Solaris using
Sun/Oracle studio
compilers.

However, on Linux compiled with GCC, if an exception gets raised in the
Python callback the
program segfaults. Obviously the C part of the vendor library has not
been compiled with
(GCC-) exception support for Linux.

Unfortunately this isn't under my control and the library provider
seems not to be willing
to make the library robust against exceptions in user callback code.

So I need to keep the Boost C++ exception that "signals" the Python
exception from passing
through the C parts.

How does the library handle callbacks? An event loop in a separate
thread? Do you have to explicitly call some blocking function to run the
event loop?

Yes. There's a separate thread that schedules events to a queue being
dispatch in the main loop, in the main thread.
And yes, there's a blocking call to a dispatch method with the possibility
of a timeout or alternatively a non-blocking poll call (we make sure to properly
release&  reacquire the Python GIL during blocking).

If it's a C lib likely the callbacks are just function pointers. Being
called inside a C object I'd say you assumption is correct: no C++
exceptions to be
raised inside callbacks (the lib is gcc-compiled, it has no knowledge of
exceptions).

Correct, the callbacks are function pointers from the C libs point of view.

If you could recompile with g++ the exception would raise from the
event loop,
unless catched while calling the callback function pointer.

While I do have the C++ sources (to be able to recompile for different C++
compilers)
I don't have the C sources so I unfortunately I can't recompile the C-lib
parts with
exceptions support.
Sidenote: For Oracle/Sun Solaris Studio compilers this isn't a problem as
you basically can't
and don't need to switch the exception support of the compiler for mixing C
and C++ code
(http://www.oracle.com/technetwork/articles/servers-storage-dev/mixingcandcpluspluscode-305840.html)

I have found a couple of references.
http://gcc.gnu.org/onlinedocs/gcc/Link-Options.html (see static-libgcc)
http://gcc.gnu.org/wiki/Visibility

The proprietary lib is shared, right? linked to? shared? static?

Sidenote: how does the C++ exception mechanism work under the hood? What
happens if it's called inside a C compiled function?

Not sure if I understand your question correctly, but:
- Solaris Studio compilers: An exception raised in a C++ compiled function
that got called
from a C compiled function called from a C++ main will properly propagate
to the main caller
- GCC: An exception raised in a C++ compiled function that got called
from a C compiled function called from a C++ main will
   - segfault if the C compiled function hasn't been compiled with exception
support (-fexceptions)
   - properly propagate to the main caller if the C compiled function has
been compiled with exception support

Well, I was thinking about ASM level :-)

--
            Giuseppe Corbelli
WASP Software Engineer, Copan Italia S.p.A
Phone: +390303666318  Fax: +390302659932
E-mail: giuseppe.corbe...@copanitalia.com
_______________________________________________
Cplusplus-sig mailing list
Cplusplus-sig@python.org
http://mail.python.org/mailman/listinfo/cplusplus-sig

Reply via email to