Re: Interlanguage condition signalling and handling

>>>>> "Joerg-Cyril" == Joerg-Cyril Hoehle <Hoehle> writes:

    Joerg-Cyril> Liam M. Healy writes:
    >> I have need of being able to signal a condition in a C library
    Joerg-Cyril> It's unclear to me what conditions there could be in C.
    Joerg-Cyril> Do you mean C++ signals or exceptions (or whatever they're called)?

When an error occurs, the library calls a user-definable routine with
a text string describing the error.  You can do anything you write in
that routine; by default it prints the string and calls abort().  I
would like signal a CL error of an appropriate type with the text
string.


    Joerg-Cyril> It's unclear to me what your exact situation is. However (being proactive):

    Joerg-Cyril> Here's for the FFI HowTo:
    Joerg-Cyril> -------------
    Joerg-Cyril> Don't throw exceptions across language barriers (foreign language interfaces) - you'll almost certainly cause unreliable behaviour! UNWIND-PROTECT and its C++ counterparts won't fully work.
    Joerg-Cyril> -------------

How about a throw to a catch?

    Joerg-Cyril> If you need this functionality, use a framework that supports passing exceptions across language barriers. CORBA is the only thing that comes to mind (I never used it). Perhaps Java RMI also has hints on how to do that.

Don't know much about CORBA, except that in ACL it's an expensive
add-on.  I'd like to stick with a more widespread interface if
possible.  

    >> they suggested a solution that required wrapping every function.
    Joerg-Cyril> Use macros for repetitive work!

But that doesn't avoid the need to wrap everything.  And by the way,
it's the C functions that need wrapping, so no nice CL macros here.

    Joerg-Cyril> I repeat: foreign C++ code must *not* throw an exception through into your Lisp system (I'm not saying they are forbidden).
    Joerg-Cyril> Likewise, a foreign callback written in Lisp must not THROW into your main Lisp loop. It must return to the foreign world via the callback. The dumb IGNORE-ERRORS is useful for this w.r.t. exception catching.

This sounds discouraging.

    Joerg-Cyril> The reason is that the run-time support libraries of each language know nothing about the other language. So they will not unwind the other language's stack frames properly. You must stick to "functional" (C-like) behaviour across different implementations and not jump.

In this case, the C error-handling routine, since it's user-defined,
may be written specifically with Lisp in mind.  That might make it a
little easier.  What if you catch the error immediately as it's
returned from C - i.e., wrap the CL function calling the C function
with an unwind-protect.  Does that mitigate the CL frame-stack
unwinding problem?

    Joerg-Cyril> The same restriction remains for all sorts of library callbacks, even within a single language. I've seen broken GUI code which would jump out of the GUI event loop. You should treat all other .so or .dll files as possibly written in a foreign language.

No GUI here, if that helps.  There is no event loop.  Just very bad
behavior now: the default routine prints the message and aborts,
killing ACL.  At the very least, I'd like to avoid killing ACL, at the
best, I'd like to signal a CL error.  In-between would be to print the
message (via C or CL) and return meaningless values, but that's only a
hair better than aborting, because the program doesn't find out there
was an error.

Liam