Re: Re: Réf. :c++ exceptions and signals

[Alfred Perlstein <bright at hotjobs dot com>]

On Mon, 11 Jan 1999, Paul Forgey wrote:

> Forgive me for wandering this a bit, but it brings up a question, perhaps a
> stupid one, but I have more experience on Win32 with stuff like this..
> 
> I can see how exceptions and signals cannot be both the same, unlike, say,
> Win32, where the stack is unwound rather than letting the code return from
> interrupt, allowing destructors to be called.  But that also spells disaster
> if your signal handler never returns :).
> 
> So if I set up a try()/throw()/catch(), can it (and if so, how?) catch a
> SIGFPE, SIGTERM, SIGILL, etc, with the same semantics as a throw() ?  Is
> there definative documentation on this somewhere?

signals are sent by the OS, signals can arrive at ANY time (well sometimes
it's restricted by the OS) this means they can come in in the middle of an
malloc, stdio function etc, signals are NOT the safe place to mess with
your buffers.

exceptions are controlled and synchranous, meaning in the path of your
program a condition is detected and code executes to handle it, with
signals you could be in the middle of anything, and one may interupt your
program.

you can queue/ignore signals, but then you steal the whole signal concept
from c++ programmers and slow the code down.

what you'll want to do is setup signal handlers to modfiy a global
'volalitile' variable, your try()/throw()/catch() will be replaced with
polling on those variables that are set within the signal handler, but
then.... how do you handle multiple signals before your poll? multiple
signals of different types?

it's not impossible, but you should definetly sit down for a bit to plan
out the semantics.

-Alfred


> 
> -----Original Message-----
> From: Joe Buck <jbuck@Synopsys.COM>
> To: Didier.Spezia@sip.fr <Didier.Spezia@sip.fr>
> Cc: Peter.Maunz@uni-konstanz.de <Peter.Maunz@uni-konstanz.de>;
> egcs@cygnus.com <egcs@cygnus.com>
> Date: Monday, January 11, 1999 10:54 AM
> Subject: Re: Réf. :c++ exceptions and signals
> 
> 
> >> You can't throw an exception from a signal handler.
> >>
> >> There is a workaround but I think it's a dirty trick :
> >> the basic idea is to use setjmp/longjmp to exit the
> >> signal handler and jump back into the block
> >> associated with the try/catch to throw the exception.
> >
> >The problem with your workaround is that destructors for any automatic
> >objects constructed after the setjmp call and still alive at the longjmp
> >call will not be invoked, resulting in memory leaks.
> >
> >If we really wanted to permit exceptions from signal handlers, we'd
> >need to invent some mechanism to queue the exception and throw it
> >at "safe" points.  But there would be overhead for this: some sort of
> >polling and/or locking would need to be added.
> >
>