🚀 go-pugleaf

Throwing an exception from within a signal handler is not valid ANSI
C++, if you do so, you do so at your own risk.  I have tried to make
the compiler (g++) so that exceptions can be asynchronous (thrown from
inside signal handlers and everything just work), but some items
remain it you want it to work flawlessly all the time.  It should work
ok some/most of the time now.

If you run the instruction stream up to the next call instruction
before throwing the exception you should be really safe.

In article <19960729171049.0-orville@weyrich.com>,
Orville R. Weyrich, Jr. <orville@weyrich.com> wrote:
>But I didn't notice any treatment of how (not) to catch UNIX
>signals and turn them into exceptions, so that the benefits of
>exception handling can be obtained.

In article <19960729171049.0-orville@weyrich.com>,
Orville R. Weyrich, Jr. <orville@weyrich.com> wrote:
>But I didn't notice any treatment of how (not) to catch UNIX
>signals and turn them into exceptions, so that the benefits of
>exception handling can be obtained.

There isn't a portable way :-( although I had heard that the ANSI/ISO 
committee were looking at this issue.

Aside from this there are effectively two types of signals - user
type signals (SIGUSR,SIGCONT,SIGSTOP) - and catestrophic failures
(eg. segmentation violations, etc).

The later should not be dealt with using exceptions - as they may already 
have been caused by an exception (causing an infinite loop !!).

The former are not "exceptions" as such - they are just expected data -
which you may not have designed your system to expect.

IMHO, it is for these reasons that exceptions should not be mixed with signals.

However, having said this there are ways to write code which will work
and will produce an exception - although not necessarily immediately.

>In particular, if I throw an exception from inside a signal
>handler, does the runtime system know what code I was executing
>when the signal was caught, so that the exception handler stack can
>be properly unwound?  I am afraid that the answer to this question
>is implementation-dependent.

It is more than likely it will not work.  As you guessed it is not only
implementation dependant but also within an implementation, machine 
dependant.

Have fun,

Rohan
-- 
Rohan Lenard - rjl@wr.com.au rjl@iassf.easams.com.au rjl@triode.apana.org.au
+61-4-11250024		| All quotes can be attributed to my automated quote
+61-2-93674555		| writing tool.  Yours for just $19.95; and if you
<gnu service provider>	| call now you'll get a free set of steak knives ...

In article <4u8njq$fe9@noise.ucr.edu> thp@cs.ucr.edu (Tom Payne) writes:

>  Mike Stump <mrs@cygnus.com> wrote:
>  : Throwing an exception from within a signal handler is not valid ANSI
>  : C++, if you do so, you do so at your own risk.  I have tried to make
>  : the compiler (g++) so that exceptions can be asynchronous (thrown from
>  : inside signal handlers and everything just work), but some items
>  : remain it you want it to work flawlessly all the time.  It should work
>  : ok some/most of the time now.
>
>  : If you run the instruction stream up to the next call instruction
>  : before throwing the exception you should be really safe.
>
>  What if the signal arrives in the middle of processing a call or
>  return, say between the time that the stack pointer is adjusted and
>  the time that the return linkage is saved?  Do you shrinkwrap those
>  parts of the code, e.g., by blocking signals?  If you really
>  have a solution, I'm be most grateful, because I can use it to
>  implement asynchronous thread termination.
>
>  Tom Payne (thp@cs.ucr.edu)

I've tried this, admittedly with a different compiler, but I ran into
a theoretical problem with it.  Do you have any way to mask out
further signals during the stack unwinding?  If you don't, then you
could get simultaneous exceptions, one of which could try to throw out
of a destructor during stack unwinding (no good).  If you do, when/how do
you unmask?  I tried to unmask on the destruction of the thrown
exception.  Since the exception evidently may be copied at the
throw, that's not perfect.  Even so a pending signal would be
thrown out of the destructor of the exception when it's run in the
catch block. Sun's compiler, at least, still considers that to be
"during stack unwinding" and hence refuses to allow it.

	Benjamin Scarlet
	Grad Student
	MIT Center for Theoretical Physics

Benjamin Scarlet <scarlet@ctpa04.mit.edu> wrote:
: In article <4u8njq$fe9@noise.ucr.edu> thp@cs.ucr.edu (Tom Payne) writes:

: >  Mike Stump <mrs@cygnus.com> wrote:
: >  : Throwing an exception from within a signal handler is not valid ANSI
: >  : C++, if you do so, you do so at your own risk.  I have tried to make
: >  : the compiler (g++) so that exceptions can be asynchronous (thrown from
: >  : inside signal handlers and everything just work), but some items
: >  : remain it you want it to work flawlessly all the time.  It should work
: >  : ok some/most of the time now.
: >
: >  : If you run the instruction stream up to the next call instruction
: >  : before throwing the exception you should be really safe.
: >
: >  What if the signal arrives in the middle of processing a call or
: >  return, say between the time that the stack pointer is adjusted and
: >  the time that the return linkage is saved?  Do you shrinkwrap those
: >  parts of the code, e.g., by blocking signals?  If you really
: >  have a solution, I'm be most grateful, because I can use it to
: >  implement asynchronous thread termination.
: >
: >  Tom Payne (thp@cs.ucr.edu)

: I've tried this, admittedly with a different compiler, but I ran into
: a theoretical problem with it.  Do you have any way to mask out
: further signals during the stack unwinding?  If you don't, then you
: could get simultaneous exceptions, one of which could try to throw out
: of a destructor during stack unwinding (no good).  If you do, when/how do
: you unmask?  I tried to unmask on the destruction of the thrown
: exception.  Since the exception evidently may be copied at the
: throw, that's not perfect.  Even so a pending signal would be
: thrown out of the destructor of the exception when it's run in the
: catch block. Sun's compiler, at least, still considers that to be
: "during stack unwinding" and hence refuses to allow it.

I understand that the standard provides for the user to call an
"unhandled expection" test that tells whether exception handling
is underway.  Perhaps your signal handlers could invoke this test
before deciding to throw an exception.

Tom Payne (thp@cs.ucr.edu)

In article <4u8njq$fe9@noise.ucr.edu>, Tom Payne <thp@cs.ucr.edu> wrote:
>What if the signal arrives in the middle of processing a call or
>return, say between the time that the stack pointer is adjusted and
>the time that the return linkage is saved?

Currently, you probably die.

>Do you shrinkwrap those parts of the code, e.g., by blocking signals?

That could be done.

>If you really have a solution, I'm be most grateful, because I can
>use it to implement asynchronous thread termination.

I know of solutions, but I don't `have' any, as in code.

Mike Stump <mrs@cygnus.com> wrote:
: Throwing an exception from within a signal handler is not valid ANSI
: C++, if you do so, you do so at your own risk.  I have tried to make
: the compiler (g++) so that exceptions can be asynchronous (thrown from
: inside signal handlers and everything just work), but some items
: remain it you want it to work flawlessly all the time.  It should work
: ok some/most of the time now.

: If you run the instruction stream up to the next call instruction
: before throwing the exception you should be really safe.

What if the signal arrives in the middle of processing a call or
return, say between the time that the stack pointer is adjusted and
the time that the return linkage is saved?  Do you shrinkwrap those
parts of the code, e.g., by blocking signals?  If you really
have a solution, I'm be most grateful, because I can use it to
implement asynchronous thread termination.

Tom Payne (thp@cs.ucr.edu)

In article <ed7mrb1azl.fsf@ctpa04.mit.edu>,
Benjamin Scarlet <scarlet@ctpa04.mit.edu> wrote:
: I've tried this, admittedly with a different compiler, but I ran into
: a theoretical problem with it.  Do you have any way to mask out
: further signals during the stack unwinding?  If you don't, then you
: could get simultaneous exceptions, one of which could try to throw out
: of a destructor during stack unwinding (no good).  If you do, when/how do
: you unmask?  I tried to unmask on the destruction of the thrown
: exception.  Since the exception evidently may be copied at the
: throw, that's not perfect.  Even so a pending signal would be
: thrown out of the destructor of the exception when it's run in the
: catch block. Sun's compiler, at least, still considers that to be
: "during stack unwinding" and hence refuses to allow it.
: 

sigaction/sigvector mechanisms allow you to specify what happens during
a signal handler.  I believe that on most systems, this defaults to
"queue it".  Given this, you just set a new signal handler (SIG_IGN) during
your signal handler - thus preventing any signals occuring during the
throw ....  In the object being throw'n you can always reset the vector
to the original handler.


Rohan
-- 
Rohan Lenard - rjl@wr.com.au rjl@iassf.easams.com.au rjl@triode.apana.org.au
+61-4-11250024		| All quotes can be attributed to my automated quote
+61-2-93674555		| writing tool.  Yours for just $19.95; and if you
<gnu service provider>	| call now you'll get a free set of steak knives ...

In article <4ub73f$4ne@rtl.cygnus.com>, Mike Stump <mrs@cygnus.com> wrote:
>In article <4u8njq$fe9@noise.ucr.edu>, Tom Payne <thp@cs.ucr.edu> wrote:
>>What if the signal arrives in the middle of processing a call or
>>return, say between the time that the stack pointer is adjusted and
>>the time that the return linkage is saved?
>
>Currently, you probably die.
>
>>Do you shrinkwrap those parts of the code, e.g., by blocking signals?
>
>That could be done.
>
>>If you really have a solution, I'm be most grateful, because I can
>>use it to implement asynchronous thread termination.
>
>I know of solutions, but I don't `have' any, as in code.


Is this a good idea?  My understanding of exceptions is that they were
designed to handle synchronous events, period.  Thay ain't designed for
asynchronous events, such as interrupts or UN*X signals. 

Of course, the question remains how DO you handle these, since setjmp and 
longjmp are strict no-nos in C++...


Scott


-- 
/--------------------------------------------------------------------------\
|Scott Johnson -- Professional (sometimes) SW Engineer and all-purpose Geek|
|I don't speak for nobody but myself, which everyone else is thankful for  |
\--------------------------------------------------------------------------/