Topic: Signals and Exceptions


Author: jbuck@synopsys.com (Joe Buck)
Date: 18 Aug 1994 17:32:59 GMT
Raw View
In article <IMMEL.94Aug11151303@flail.centerline.com> immel@flail.centerline.com wrote:
>>   I can't find anything in the May WP that describes how signals and
>> exceptions should interact.

muzok@microsoft.com (Muzaffer Kal) writes:
>Why do you expect to find that information in the WP ? Signals are OS specific
>features and they don't exist on every platform where C++ will exist. So wait
>for the Standard and then blame your compiler vendor for not providing such
>an interface.

While you're correct that it isn't the job of the C++ standardization
committee, I think that perhaps it should fall under some future revision
of POSIX, so that on POSIX-compliant systems the relationship between
C++ exceptions and POSIX signals is consistent.  Given that POSIX has
tackled things like support for tasks in Ada, it would seem natural that
they'd want to deal with exceptions vs signals.

One possible relationship I've seen advocated is "none at all" -- they are
completely different, no support given to throwing exceptions to signal
handlers, etc, since signals can be asynchronous to the program and
exceptions never are.  The other extreme is to have exceptions look just
like signals as far as the programmer is concerned: catching exceptions of
a particular magic class would catch signals.




--
-- Joe Buck  <jbuck@synopsys.com>
Posting from but not speaking for Synopsys, Inc.
***** Stamp out junk e-mail spamming!  If someone sends you a junk e-mail
***** ad just because you posted in comp.foo, boycott their company.




Author: nebbe@lglsun.epfl.ch (Robb Nebbe)
Date: 19 Aug 1994 09:13:20 GMT
Raw View
In article <33060b$l4b@hermes.synopsys.com>, jbuck@synopsys.com (Joe Buck) writes:
|>
|> muzok@microsoft.com (Muzaffer Kal) writes:
|> >Why do you expect to find that information in the WP ? Signals are OS specific
|> >features and they don't exist on every platform where C++ will exist. So wait
|> >for the Standard and then blame your compiler vendor for not providing such
|> >an interface.
|>
|> While you're correct that it isn't the job of the C++ standardization
|> committee, I think that perhaps it should fall under some future revision
|> of POSIX, so that on POSIX-compliant systems the relationship between
|> C++ exceptions and POSIX signals is consistent.  Given that POSIX has
|> tackled things like support for tasks in Ada, it would seem natural that
|> they'd want to deal with exceptions vs signals.
|>

In POSIX 1003.5 (the Ada equivalent of 1003.1) signals are divided into
to groups: those that are synchronous (i.e. result from the execution
of code) and asynchronous. The synchronous signals are reserved for the
run-time kernel and are delt with or turned into exceptions while the
others are just signals.

This is clearly outside the definition of a language but I would expect
an implementation to clearly state in some appendix which signals are
"reserved" or if any signals are reserved.

- Robb Nebbe





Author: rfg@netcom.com (Ronald F. Guilmette)
Date: Fri, 19 Aug 1994 09:14:34 GMT
Raw View
In article <33060b$l4b@hermes.synopsys.com> jbuck@synopsys.com (Joe Buck) writes:
>
>In article <IMMEL.94Aug11151303@flail.centerline.com> immel@flail.centerline.com wrote:
>>>   I can't find anything in the May WP that describes how signals and
>>> exceptions should interact.
>
>muzok@microsoft.com (Muzaffer Kal) writes:
>>Why do you expect to find that information in the WP ? Signals are OS specific
>>features and they don't exist on every platform where C++ will exist. So wait
>>for the Standard and then blame your compiler vendor for not providing such
>>an interface.
>
>While you're correct that it isn't the job of the C++ standardization
>committee, I think that perhaps it should fall under some future revision
>of POSIX...

Mr. Kal and Mr. Buck,

May I suggest to you both that you consider having a look *either* at the
ANSI C standard *or* at any recent copy of the X3J16/WG21 C++ standardization
committee's working drafts.

If you do, you may both become aware that (a) signals are *not* OS specific
(and that C and C++ compilers on even that... ummm... let's just say ``non-
preemptive'' system known as DOS must support them) and that (b) that are
*not* the sole responsibility of the various POSIX standardization groups
to specify (since they are already firmly entrenched in the C standard...
and have been for many years now... and they are quite likely to be a part
of the C++ standard also, given that they are already included, by reference,
into the current C++ draft standard).

--

-- Ron Guilmette, Sunnyvale, CA ---------- RG Consulting -------------------
---- domain addr: rfg@netcom.com ----------- Purveyors of Compiler Test ----
---- uucp addr: ...!uunet!netcom!rfg ------- Suites and Bullet-Proof Shoes -




Author: rfg@netcom.com (Ronald F. Guilmette)
Date: Fri, 19 Aug 1994 09:15:15 GMT
Raw View
With regard to the interaction of signal and exceptions, this is at best
still a grey area I think.  One important question which I have previously
raised with the C++ standardization committee is the question of whether or
not a signal handler routine will be allowed to throw an exception (and
whether the ensuing behavior of a program which does this will be con-
sidered to be well-defined or undefined).

The general impression I got when I raised this question was that although
it might be possible to write the standard in such a way that C++ signal
handlers would be permitted to throw exceptions without incuring the dreaded
``undefined behavior'', the majority of members who responded to the question
would prefer not to do so.

The implication being that you will probably NOT be permitted to propagate
an exception out of a signal handler in a strictly conforming program.
(Actually, there are likely to also be MANY other restrictions on what
you can and cannot do in a signal handler function, e.g. all of the
restrictions specified in the ISO C standard, subclause 7.7.1.1.)

Another interesting (and unresolved) question is the behavior of the
following signal handler function in the case where it is entered (due to
receipt of a signal) while the containing program is ALREADY handling an
exception:

 void handler (int signo)
 {
     try
     {
  throw;   // ?????
     }
     catch (...) { /* ... */ }
 }

(In theory, the re-throw might involve one or more references to statically
allocated ``secret'' variables maintained by the implementation itself, but
reads of statically allocated variables from within signal handlers are
specifically prohibited by the ISO C standard in subclause 7.7.1.1.)

--

-- Ron Guilmette, Sunnyvale, CA ---------- RG Consulting -------------------
---- domain addr: rfg@netcom.com ----------- Purveyors of Compiler Test ----
---- uucp addr: ...!uunet!netcom!rfg ------- Suites and Bullet-Proof Shoes -




Author: muzok@microsoft.com (Muzaffer Kal)
Date: Wed, 17 Aug 1994 01:34:17 GMT
Raw View
In article <IMMEL.94Aug11151303@flail.centerline.com> immel@flail.centerline.com wrote:
>   I can't find anything in the May WP that describes how signals and
> exceptions should interact.

Why do you expect to find that information in the WP ? Signals are OS specific
features and they don't exist on every platform where C++ will exist. So wait
for the Standard and then blame your compiler vendor for not providing such
an interface.

Muzaffer

only my opinions.





Author: immel@flail.centerline.com (Mark Immel)
Date: 11 Aug 1994 19:13:03 GMT
Raw View
C++ Gurus --

  I can't find anything in the May WP that describes how signals and
exceptions should interact.  In particular, consider the following code:

------------------------------------

#include <signal.h>
#include <iostream.h>

void SIGSEGV_handler(int)
{
  cout << "In the handler!" << endl;
  throw 3;
}

int main()
{
  (*signal)(SIGSEGV, SIGSEGV_handler);
  try
    {
      int* vp = 0;
      *vp = 3; /* This should cause a SIGSEGV */
    }
  catch (...)
    {
      cout << "Caught an exception!" << endl;
    }
};

----------------------------

Should the exception be caught?  What are the rules for stack unwinding,
calling destructors, etc?  <signal.h> is still a part of C++ -- we should
decide what it's behavior is.

You may send email to me -- I'll follow-up -- or post directly.

Thanks in advance.

-- Mark Immel
   immel@centerline.com

[ My opinions are my own, not necessarily those of my employer. ]