Re: cannot longjmp from g_log_set_handler function

[andrew cogent ca]

Owen Taylor writes:
 > Andrew Thomas <andrew@cogent.ca> writes:
 > 
 > > I created an error handler using g_log_set_handler that calls the
 > > error handler for a language interpreter.  The action of the
 > > interpreter is to throw an error, which entails a longjmp.  The
 > > next time an error occurs in a GTK+ function, the error handler
 > > enters again, where a global flag in the log routines says that
 > > the second entry is a recursion (falsely), due to some code that
 > > sets a global flag in the g_ error handler but never clears it on
 > > a longjmp.
 > > 
 > > I suggest that there needs to be a function that will clean up
 > > the error handler context in the event of a longjmp, so that it
 > > is possible to throw GTK+ errors.  At the moment, the g_log_
 > > function is only good for aborting a run, not for recovery.
 > 
 > Yep.
 > 
 > I'm not at all sure if I like the idea of somebody 
 > long-jumping out of a g_error()
 > 
 >  - You will almost certainly leak memory. 
 > 
 >  - You may well leave GTK+ in an inconsistent state
 >    that and may well get segfaults if you continue 
 >    using GTK+
 > 
 > g_error indicates fatal errors. 
 > 
 >                                         Owen
 > 
 > P.S. - yes, exception handling is nice; but the only
 > way to do it safely in C, IMO,  is to make all functions
 > take another parameter, and you'll end up easily
 > doubling the length and complexity of your code if
 > you do that.

Well, I thought about this, and in general I agree with you.  A
longjmp from within a callback to a point outside the callback is a
disaster waiting to happen.  My case is slightly more specific:  On
entry to my callback function I set the setjmp point, and then on a
GTK error within my callback function I longjmp back to my own
callback function.  Consequently I never jump past a callback function
boundary.  *All* callback functions are wrapped in a setjmp block.
So... is GTK architecturally capable of handling this case?  It would
mean jumping out of GTK calls in failed assertions, which typically
appear at the beginning of functions, before any persistent context
changes are made, but that does not mean that there is not static
context further up the calling chain.

Andrew