This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

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


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?

-----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.
>


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]