🚀 go-pugleaf

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