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]

th********@goog lemail.com writes:

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

[Pete Becker]

On 2008-06-09 16:54:58 +0200, th********@goog lemail.com said:

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?

From the C99 standard: "If the signal occurs other than as the result
of calling the abort or raise function, the behavior is unde�ned if the
signal handler refers to any object with static storage duration other
than by assigning a value to an object declared asvolatile
sig_atomic_t, or the signal handler calls any function in the standard
library other than the abort function, the _Exit function, or the
signal function with the �rst argument equal to the signal number
corresponding to the signal that caused the invocation of the handler.
Furthermore, if such a call to the signal function results in a SIG_ERR
return, the value of errno is indeterminate."

So, unless the signal came from a call to abort or raise, the behavior
is undefined. If your compiler tells you what it does, fine. But that's
a discussion for a different newsgroup.

--
Pete
Roundhouse Consulting, Ltd. (www.versatilecoding.com) Author of "The
Standard C++ Library Extensions: a Tutorial and Reference
(www.petebecker.com/tr1book)

[thagor2008]

On Jun 9, 4:26 pm, Pete Becker <p...@versatile coding.comwrote :

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]

th********@goog lemail.com wrote:

On Jun 9, 4:26 pm, Pete Becker <p...@versatile coding.comwrote :

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

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]

th********@goog lemail.com wrote:

On Jun 9, 4:26 pm, Pete Becker <p...@versatile coding.comwrote :

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

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").
--
Ian Collins.

[red floyd]

On Jun 9, 12:47 pm, Ian Collins <[e-mail] mwrote:

thagor2...@goog lemail.com wrote:

On Jun 9, 4:26 pm, Pete Becker <p...@versatile coding.comwrote :

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!

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

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

[Jack Klein]

On Mon, 9 Jun 2008 17:26:29 +0200, Pete Becker
<pe**@versatile coding.comwrote in comp.lang.c++:

On 2008-06-09 16:54:58 +0200, th********@goog lemail.com said:

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?

From the C99 standard: "If the signal occurs other than as the result
of calling the abort or raise function, the behavior is unde?ned if the
signal handler refers to any object with static storage duration other
than by assigning a value to an object declared asvolatile
sig_atomic_t, or the signal handler calls any function in the standard
library other than the abort function, the _Exit function, or the
signal function with the ?rst argument equal to the signal number
corresponding to the signal that caused the invocation of the handler.
Furthermore, if such a call to the signal function results in a SIG_ERR
return, the value of errno is indeterminate."

So, unless the signal came from a call to abort or raise, the behavior
is undefined. If your compiler tells you what it does, fine. But that's
a discussion for a different newsgroup.

Even more significant, from C++98:

"The common subset of the C and C++ languages consists of all
declarations, definitions, and expressions that may appear in a well
formed C++ program and also in a conforming C program. A POF (‘‘plain
old function’’) is a function that uses only features from this common
subset, and that does not directly or indirectly use any function that
is not a POF. All signal handlers shall have C linkage. A POF that
could be used as a signal handler in a conforming C program does not
produce undefined behavior when used as a signal handler in a C++
program. The behavior of any other function used as a signal handler
in a C++ program is implementation defined."

The last sentence points to footnote 213 on the same page, which adds:

"In particular, a signal handler using exception handling is very
likely to have problems"

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://c-faq.com/
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.l earn.c-c++
http://www.club.cc.cmu.edu/~ajo/docs/FAQ-acllc.html

[Pete Becker]

On 2008-06-09 17:45:04 +0200, th********@goog lemail.com said:

On Jun 9, 4:26 pm, Pete Becker <p...@versatile coding.comwrote :

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

That C, not C++.

It is both. C++ gets its specification for signal and raise from the C
standard.

>

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

Yes, that's correct.

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

If you're interested in platform-specific behavior, you need to ask on
a newsgroup that discusses your platform. In standard C++, the behavior
is undefined.

--
Pete
Roundhouse Consulting, Ltd. (www.versatilecoding.com) Author of "The
Standard C++ Library Extensions: a Tutorial and Reference
(www.petebecker.com/tr1book)

[James Kanze]

On Jun 9, 5:45 pm, thagor2...@goog lemail.com wrote:

On Jun 9, 4:26 pm, Pete Becker <p...@versatile coding.comwrote :

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

That C, not C++.

Included in the C++ standard by reference.

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!

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.

--
James Kanze (GABI Software) email:ja******* **@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientier ter Datenverarbeitu ng
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]