In article 9np@ritz.cec.wustl.edu, jaf3@ritz.cec.wustl.edu (John Andrew Fingerhut) writes:
>In article <3kni31$g5b@engnews2.Eng.Sun.COM>, Steve Clamage <clamage@Eng.Sun.COM> wrote:
>:
>:The problem is that on some systems signal handlers run with a tiny
>:aritificial stack, and won't even support calling another function.
>:About the only portable thing you can do in a signal handler is to
>:set a global flag (preferably declared "volatile") and return.
>
>So it follows that it is undefined to invoke any operation that *may* cause
>an exception to be thrown from within a signal handler.  This seems like a
>flaw in the language to me.
The signal handling mechanism is a property of the system on which C++ runs.
The language standard could insist that a signal handler allow arbitrary code,
thus making it impossible to implement C++ (or C) on some systems. Instead,
C and C++ do not make that requirement. You just have to move the arbitrary
code out of the signal handler to some other place in the program.

Remember that signals are primarily asynchronous events, and you cannot
assume anything about the state of the program, its variables, or the
program stack during the execution of the signal handler. The language
standard thus cannot make any guarantees. Your particular system may
provide interlocks of various kinds that let you write dependable code,
but those are outside the C++ definition. C++ does not address multi-
threading at all.

---
Steve Clamage, stephen.clamage@eng.sun.com

In article <3klqep$747@engnews2.eng.sun.com>,
Steve Clamage <clamage@Eng.Sun.COM> wrote:
>kris@savantics.com (Kristian Kvilekval) writes:
>
>>Anybody know if I can use "throw" inside a signal handler (on unix) or
>>a NT exception (in a thread)?
>
>The results of throwing an exception from inside a signal handler are
>undefined. NT threads and NT exceptions are not mentioned in the C++
>language definition. Signals are part of Standard C, and are
>inherited by C++. OS-specific issues are, well, OS-specific.
>
>A particular C++ implementation might choose to support throwing
>exceptions from a signal handler, but you would have to find it
>specifically documented as safe. Otherwise, you cannot expect it to
>work. I do not know of any systems where it works.
>

Hmmm. longjmp () is supposed to work in BSD signal handlers and, in
fact, such usage is encouraged by Curry, `Using C on the Unix System',
as a way to abstract from BSD vs SysV signal semantics
differences. That would seem to imply that it works on SysV, too. So
what's the snag for exceptions? The longjmp () part seems the most
dangerous...

cheers, itz.
--
Ian T Zimmerman            +-------------------------------------------+
P.O. Box 13445             I    With so many executioners available,   I
Berkeley, California 94712 I suicide is a really foolish thing to do.  I
USA  <itz@rahul.net>       +-------------------------------------------+

Ian T Zimmerman <itz@rahul.net> writes:

>In article <3klqep$747@engnews2.eng.sun.com>,
>Steve Clamage <clamage@Eng.Sun.COM> wrote:
>>
>>The results of throwing an exception from inside a signal handler are
>>undefined. NT threads and NT exceptions are not mentioned in the C++
>>language definition. Signals are part of Standard C, and are
>>inherited by C++. OS-specific issues are, well, OS-specific.
>>
>>A particular C++ implementation might choose to support throwing
>>exceptions from a signal handler, but you would have to find it
>>specifically documented as safe. Otherwise, you cannot expect it to
>>work. I do not know of any systems where it works.
>>

>Hmmm. longjmp () is supposed to work in BSD signal handlers and, in
>fact, such usage is encouraged by Curry, `Using C on the Unix System',
>as a way to abstract from BSD vs SysV signal semantics
>differences. That would seem to imply that it works on SysV, too. So
>what's the snag for exceptions? The longjmp () part seems the most
>dangerous...

Longjmp has almost no semantics, except that execution continues from
the point of the previous setjmp. Exceptions have elaborate semantics.
Here is a simple example Neal Gafter uses to illustrate the problem:

    char *p = 0;
    try {
 p = (char*) malloc(100);
    }
    catch( int )
    {
 free(p);
 p = 0;
    }

Let's suppose that malloc itself is safe, and that the heap is
known not to be corrupted by any signal.

Further suppose that a signal happens after malloc returns but
before the result is assigned to p (signals may be asynchronous),
and that the signal handler throws an int.

We cannot be sure the allocated memory is freed in the catch clause.
If this trivial piece of code doesn't have known semantics in the
presence of exceptions thrown from signal handlers, what hope is
there for real programs?
--
Steve Clamage, stephen.clamage@eng.sun.com

In article <3kni31$g5b@engnews2.Eng.Sun.COM>,
Steve Clamage <clamage@Eng.Sun.COM> wrote:
:In article 95Mar21160858@ground.cs.columbia.edu, fenster@ground.cs.columbia.edu (Sam Fenster) writes:
:>
:>So, given that almost any C++ code can throw an exception, and signals are
:>part of C++, is it well-defined to throw an exception in a signal handler IF
:>IT IS CAUGHT IN THE SIGNAL HANDLER?
:
:How much you can do in a signal handler is up to the implementation.
:There is no specific prohibition against throwing and catching an
:exception from a signal handler, but there is no guarantee that it
:will work, either. (As opposed to *exiting* a signal handler via an
:exception, which is unlikely to work anywhere.)
:
:The problem is that on some systems signal handlers run with a tiny
:aritificial stack, and won't even support calling another function.
:About the only portable thing you can do in a signal handler is to
:set a global flag (preferably declared "volatile") and return.
:
:---
:Steve Clamage, stephen.clamage@eng.sun.com
:
:

So it follows that it is undefined to invoke any operation that *may* cause
an exception to be thrown from within a signal handler.  This seems like a
flaw in the language to me.

--
Stephen Gevers
sg3235@shelob.sbc.com

In article <FENSTER.95Mar21160858@ground.cs.columbia.edu>,
Sam Fenster <fenster@ground.cs.columbia.edu> wrote:
>
>So, given that almost any C++ code can throw an exception, and signals are
>part of C++, is it well-defined to throw an exception in a signal handler IF
>IT IS CAUGHT IN THE SIGNAL HANDLER?

Throwing an exception causes well-defined behavior except where the (draft)
standard says it doesn't.

Now, would anyone care to help us all out and quote for us the chapter and
verse of any prohibitions relating to exception propagation which might
be present in the latest draft?

--

-- Ron Guilmette, Sunnyvale, CA ---------- RG Consulting -------------------
---- E-mail: rfg@segfault.us.com ----------- Purveyors of Compiler Test ----
-------------------------------------------- Suites and Bullet-Proof Shoes -

clamage@Eng.Sun.COM (Steve Clamage) writes:
> kris@savantics.com (Kristian Kvilekval) writes:

>> Anybody know if I can use "throw" inside a signal handler (on unix) or a NT
>> exception (in a thread)?

> ...The results of throwing an exception from inside a signal handler are
> undefined....Signals are part of Standard C, and are inherited by C++....

> Exceptions of are part of C++, and the C++ standard library contains
> standard exception classes corresponding to those thrown by language
> operations (e.g., a failed dynamic cast), as well as those defined to be
> thrown by selected library functions (e.g., by operator new). This is a
> subject unrelated to signals and signal handlers.

So, given that almost any C++ code can throw an exception, and signals are
part of C++, is it well-defined to throw an exception in a signal handler IF
IT IS CAUGHT IN THE SIGNAL HANDLER?

In article 95Mar21160858@ground.cs.columbia.edu, fenster@ground.cs.columbia.edu (Sam Fenster) writes:
>
>So, given that almost any C++ code can throw an exception, and signals are
>part of C++, is it well-defined to throw an exception in a signal handler IF
>IT IS CAUGHT IN THE SIGNAL HANDLER?

How much you can do in a signal handler is up to the implementation.
There is no specific prohibition against throwing and catching an
exception from a signal handler, but there is no guarantee that it
will work, either. (As opposed to *exiting* a signal handler via an
exception, which is unlikely to work anywhere.)

The problem is that on some systems signal handlers run with a tiny
aritificial stack, and won't even support calling another function.
About the only portable thing you can do in a signal handler is to
set a global flag (preferably declared "volatile") and return.

---
Steve Clamage, stephen.clamage@eng.sun.com

Anybody know if I can use "throw" inside a signal handler (on unix) or
a NT exception (in a thread)?
  Are compiler makers supposed to tie their Runtime
Libraries in with C++ exceptions?  Is the behaviour just undefined
or strictly prohibited.

Thanks,
Kris

kris@savantics.com (Kristian Kvilekval) writes:

>Anybody know if I can use "throw" inside a signal handler (on unix) or
>a NT exception (in a thread)?

The results of throwing an exception from inside a signal handler are
undefined. NT threads and NT exceptions are not mentioned in the C++
language definition. Signals are part of Standard C, and are
inherited by C++. OS-specific issues are, well, OS-specific.

A particular C++ implementation might choose to support throwing
exceptions from a signal handler, but you would have to find it
specifically documented as safe. Otherwise, you cannot expect it to
work. I do not know of any systems where it works.

>  Are compiler makers supposed to tie their Runtime
>Libraries in with C++ exceptions?  Is the behaviour just undefined
>or strictly prohibited.

Exceptions of are part of C++, and the C++ standard library contains
standard exception classes corresponding to those thrown by
language operations (e.g., a failed dynamic cast), as well as
those defined to be thrown by selected library functions (e.g.,
by operator new). This is a subject unrelated to signals and
signal handlers.
--
Steve Clamage, stephen.clamage@eng.sun.com

In article <3kl21l$d9l@NewMedia.comptons.com>, <kris@savantics.com> writes:
> Anybody know if I can use "throw" inside a signal handler (on unix) or
                                             ************************
> a NT exception (in a thread)?
    &&&&&&&&&&&&&&&&&&&&&&&&&&&

* Unix signals are very restricted beasts. You can't normally call malloc
in a signal handler (most of the time only if malloc is running when you
got a signal, basically malloc is not re-entrant). So most probably it is
not safe to do so.

& Simply yes. But remember NT exceptions are not c++ exceptions. You generate
them using RaiseException not throw. But you can catch an NT exception with
catch.

>   Are compiler makers supposed to tie their Runtime
> Libraries in with C++ exceptions?  Is the behaviour just undefined
> or strictly prohibited.
>
> Thanks,
> Kris
>

I believe signal is part of the standard c library. So there is a greater
chance that C++ standard will specify what you can/can't do in a signal
handler than it will say anything about NT. (this comment makes this post
relevant in this group ;-)

hope this helps

Muzaffer

standard disclaimer