Throwing exceptions in a unix signal handler. Good idea?

[thagor2008]

Is the behaviour of throwing exceptions in a unix signal handler
defined?

eg:

void sighandler(int sig)
{
... do something
throw myobj;
}

Under gcc on linux it seems to work as I'd expect - ie the exception
handler wrapping the code running when the signal was caught catches
the exception, but no one I've asked seems sure if this is how it
should work or its just the gcc way of doing it.

Can anyone shed any light on this?

Thanks

B2003

 

[Pascal J. Bourguignon]

Is the behaviour of throwing exceptions in a unix signal handler
defined?

eg:

void sighandler(int sig)
{
... do something
throw myobj;
}

Under gcc on linux it seems to work as I'd expect - ie the exception
handler wrapping the code running when the signal was caught catches
the exception, but no one I've asked seems sure if this is how it
should work or its just the gcc way of doing it.

Can anyone shed any light on this?

It's not a good idea.

First, if it works with your compiler on your kernel, it may very well
(and most probably) not work with another compiler or on another
kernel.

And even with your compiler on your kernel, if you add multithreads,
there's no guarantee in which thread the signals are processed.

Also, some syscalls may be interrupted by signals, with some exit code
indicating it, to let the program retry the syscall. If you throw an
exception from the signal handler, you may leave an unstable state.
It means that this exception can be thrown from any place, not only to
the very localized places where you call a function that throws it.

So I would definitely not do that.

 

[thagor2008]

From the C99 standard: "If the signal occurs other than as the result

That C, not C++.

So, unless the signal came from a call to abort or raise, the behavior
is undefined.

It may be undefined from the point of view of the C standard , but not
from the unix standard otherwise there'd be no point using signals -
every time a handler was called you'd have to hold your breath and
hope the program didn't crash!

I'm only interested in the specific combination of C++ exceptions and
signal handlers since once stores the stack and one forces an unwind.
Are compilers smart enough to know to pop the signal handler stack
first and return to where the signal occured before unwinding the
stack for the exception is the question.

B2003

 

[Noah Roberts]

That C, not C++.


It may be undefined from the point of view of the C standard , but not
from the unix standard otherwise there'd be no point using signals -
every time a handler was called you'd have to hold your breath and
hope the program didn't crash!

You still need to ask in the OS/compiler specific newsgroup that can
tell you the mechanics of that system. C++ says nothing about it and it
works differently on the different systems.

 

[Ian Collins]

That C, not C++.


It may be undefined from the point of view of the C standard , but not
from the unix standard otherwise there'd be no point using signals -
every time a handler was called you'd have to hold your breath and
hope the program didn't crash!

It is also undefined in the C++ standard, which refers to the C standard.

I'm only interested in the specific combination of C++ exceptions and
signal handlers since once stores the stack and one forces an unwind.
Are compilers smart enough to know to pop the signal handler stack
first and return to where the signal occured before unwinding the
stack for the exception is the question.

Only a platform specific group could answer that. There isn't a
portable standard C++ answer (other than "it's undefined").

 

[red floyd]

It is also undefined in the C++ standard, which refers to the C standard.


Only a platform specific group could answer that. There isn't a
portable standard C++ answer (other than "it's undefined").

Ian is right. The Linux g++ docs flat out say it's undefined.

 

[James Kanze]

That C, not C++.

Included in the C++ standard by reference.

It may be undefined from the point of view of the C standard ,
but not from the unix standard otherwise there'd be no point
using signals - every time a handler was called you'd have to
hold your breath and hope the program didn't crash!

Not if you only do things which are allowed in the signal
handler. Posix allows you to call a certain number of system or
library functions, in addition to what the C standard allows,
but it's still very limited. (Of course, if you're only under
Posix, you won't be using signal() anyway.)

I'm only interested in the specific combination of C++
exceptions and signal handlers since once stores the stack and
one forces an unwind. Are compilers smart enough to know to
pop the signal handler stack first and return to where the
signal occured before unwinding the stack for the exception is
the question.

The problem is that signals can arrive asynchronously. At a
moment, for example, when the stack frame isn't set up
correctly, and stack walkback isn't possible. In practice, it
is very, very difficult to implement it so that it can work
reliably, and I know of no system which does so.