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

thagor2008@googlemail.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__

On 2008-06-09 16:54:58 +0200, thagor2008@googlemail.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)

On Jun 9, 4:26 pm, Pete Becker <p...@versatilecoding.com> wrote:
> 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

thagor2008@googlemail.com wrote:
> On Jun 9, 4:26 pm, Pete Becker <p...@versatilecoding.com> wrote:
>> 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.

thagor2008@googlemail.com wrote:
> On Jun 9, 4:26 pm, Pete Becker <p...@versatilecoding.com> wrote:
>> 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.

On Jun 9, 12:47 pm, Ian Collins <ian-n...@hotmail.com> wrote:
> thagor2...@googlemail.com wrote:
> > On Jun 9, 4:26 pm, Pete Becker <p...@versatilecoding.com> wrote:
> >> 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.

On Mon, 9 Jun 2008 17:26:29 +0200, Pete Becker
<pete@versatilecoding.com> wrote in comp.lang.c++:

> On 2008-06-09 16:54:58 +0200, thagor2008@googlemail.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.learn.c-c++
http://www.club.cc.cmu.edu/~ajo/docs/FAQ-acllc.html