🚀 go-pugleaf

In article <4cpmh0$ltf@natasha.rmii.com>, jtc@rmii.com (Jim Cochrane) wrote:

>> Does the proposed ANSI standard say anything about throwing an exception
>> from within a signal handler?  Is the resulting behavior safe and
well-defined,
>> or is it undefined or implementation-dependent?
>> 

Again, I wonder why this passed the moderation ...

signal handlers is a C++ issue ? come on ...

-- 
-- Etay Bogner,
-- Etay_Bogner@mail.stil.scitex.com,
-- Scitex Corp.
-- Israel.
---
[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]

Etay_Bogner@mail.stil.scitex.com (Etay Bogner) writes:

>In article <4cpmh0$ltf@natasha.rmii.com>, jtc@rmii.com (Jim Cochrane) wrote:
>
>>> Does the proposed ANSI standard say anything about throwing an exception
>>> from within a signal handler?

No.

>>> Is the resulting behavior safe and
>>> well-defined, or is it undefined or implementation-dependent?

Because the draft standard doesn't say anything about it,
I guess it is implicitly undefined behaviour.

>Again, I wonder why this passed the moderation ...
>
>signal handlers is a C++ issue ? come on ...

I think the issue of whether the standard says anything about *Foo* is
generally appropriate to comp.std.c++, even if the answer is "No.", and
the resulting discussion rather short.

P.S. Probably Etay Bogner's meta-post should not have got past moderation ;-)
As a reminder, comments on the moderation policy should be addressed
c++-std-request@ncar.ucar.edu.

--
Fergus Henderson             	WWW: http://www.cs.mu.oz.au/~fjh
fjh@cs.mu.oz.au              	PGP: finger fjh@128.250.37.3

In article <Etay_Bogner-0901961008510001@metay.stil.scitex.com> Etay_Bogner@mail.stil.scitex.com (Etay Bogner) writes:

> >> Does the proposed ANSI standard say anything about throwing an exception
> >> from within a signal handler?  Is the resulting behavior safe and
> well-defined,
> >> or is it undefined or implementation-dependent?
> >> 
> 
> Again, I wonder why this passed the moderation ...
> 
> signal handlers is a C++ issue ? come on ...

Maybe it's time for another discussion about revising the moderation
policy.  I suggest that anyone who is interested in such a discussion
send mail to std-c++-request@ncar.ucar.edu, though: it doesn't really
belong in this group.

Under the current policy, at least, we almost always accept articles
asking whether the standard says anything about a subject.  There are
limits, but an article like that would have to get pretty outlandish
before we'd reject it.  I don't think it's ridiculous to wonder
whether the C++ standard says anything about signals or threads, or
whether it should; some languages, after all, do address those issues
specifically.  C++ simply doesn't happen to be one of them.

At present, the moderation policy (http://dogbert.lbl.gov/~matt/std-c++)
doesn't have any absolute prohibition against FAQs or against
questions that could easily be answered by reading the draft standard.
Perhaps it should.  (Although there's always the question of just
where to draw the line...)  I'd be interested in hearing people's
comments on this issue.  Again, though, please email those comments to
std-c++-request@ncar.ucar.edu.
---
[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]

Fergus Henderson (fjh@munta.cs.mu.OZ.AU) wrote:

> Because the draft standard doesn't say anything about it,
> I guess it is implicitly undefined behaviour.

> >Again, I wonder why this passed the moderation ...

Because signals are a part of ANSI C, and we really need to address at
least all ANSI C issues as part of any C++ standard?

	[Yes. -Moderator (fjh).]

--
Shankar Unni				E-Mail:	shankar@sgi.com
Silicon Graphics Inc.			Phone:	+1-415-933-2072
URL:	http://reality.sgi.com/employees/shankar
---
[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]

Fergus Henderson (fjh@munta.cs.mu.OZ.AU) wrote:
: 
: >In article <4cpmh0$ltf@natasha.rmii.com>, jtc@rmii.com (Jim Cochrane) wrote:

: >>>
: >>> Does the proposed ANSI standard say anything about throwing an exception
: >>> from within a signal handler?
: 
: No.
: 
: >>> Is the resulting behavior safe and
: >>> well-defined, or is it undefined or implementation-dependent?
: 
: Because the draft standard doesn't say anything about it,
: I guess it is implicitly undefined behaviour.
: 
[...]
: 
: I think the issue of whether the standard says anything about *Foo* is
: generally appropriate to comp.std.c++, even if the answer is "No.", and
: the resulting discussion rather short.

Implicit in a qestion of what the Standard says are the related
questions of what it should say and why --- why shouldn't signal
handlers be allowed to throw exceptions?  (The question seems both
interesting and appropriate.)

Tom Payne (thp@cs.ucr.edu)
---
[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]

In article <4dekiv$22h@galaxy.ucr.edu> thp@cs.ucr.edu (Tom Payne)
writes:

|> Implicit in a qestion of what the Standard says are the related
|> questions of what it should say and why --- why shouldn't signal
|> handlers be allowed to throw exceptions?  (The question seems both
|> interesting and appropriate.)

Because of the problems related to atomicity which crop up when
asynchronous events are considered.

From an implementation point of view, it would introduce a number of
constraints, which could possibly have a negative effect on
performance.  Handling an exception involves unwinding the stack,
which in turn involves exploiting a known stack structure.  On
entering a function, the compiler typically generates code to set up a
new stack frame.  At present, there is no requirement that this code
be `atomic' in any way; allow an asynchronous exception, and extra
precautions must be taken.

From a user point of view, asynchronous exceptions introduce severe
constraints on the types that can be thrown.  Basically, because of
the constraints concerning atomicity, the C standard greatly restrains
what an implementation may do in a signal handler; these restraints
would in turn so limit the types you can throw as to make them
useless.  Basically, even if the implementation problems above were
considered acceptable cost, the best the standard could do is
guarantee that you could throw a sig_atomic_t.

Potentially, I suppose, the standard could make more guarantees
concerning synchronous signals (those raised by `abort' or `raise');
in fact, the C standard does.  Is it worth it?

There is one practical case that might be worth discussing: SIGFPE.  I
don't think that the standard can make too many guarantees about this
one, since on some hardware, it is asynchronous.  But on many
implementations, it is synchronous, or close enough to being
synchronous, so that you could throw an exception from it.  It would
be nice, as a quality of implementation issue, if such implementations
actually documented this fact, and the fact that you could count on
it.

--
James Kanze         Tel.: (+33) 88 14 49 00        email: kanze@gabi-soft.fr
GABI Software, Sarl., 8 rue des Francs-Bourgeois, F-67000 Strasbourg, France
Conseils, itudes et rialisations en logiciel orienti objet --
                -- A la recherche d'une activiti dans une region francophone
---
[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]

Shankar Unni (shankar@engr.sgi.com) wrote:
:
: > >Again, I wonder why this passed the moderation ...
: 
: Because signals are a part of ANSI C, and we really need to address at
: least all ANSI C issues as part of any C++ standard?
: 
: 	[Yes. -Moderator (fjh).]

Are all moderators in agreement that comp.std.c++ is an appropriate
forum for discussiong what the semantics of signal handling are and
should be in C++ (even though the current semantics are inherited
from C)?

Tom Payne (thp@cs.ucr.edu)

[ Yes. Discussions about what is in the standard and what should be
  in the standard are part of the charter of this news group.
  In particular, C++ is not purely a superset of C.  -Moderator (sdc) ]

[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]