🚀 go-pugleaf

J. Kanze (kanze@gabi.gabi-soft.fr) wrote:
: In article <DLCosx.Hn1@falcon.daytonoh.attgis.com> Dick Menninger
: <Dick.Menninger@daytonoh.attgis.com> writes:
: 
: > > ==========Steve Clamage, 1/16/96==========
: > > In C, a signal handler isn't allowed to do much of anything, precisely
: > > because the program state can't be known and may be inconsistent. The
: > > same is true in C++.
: 
: > It is just like an interrupt handler in that it could
: > deadlock with the code it preempts.  OSes deal with
: > that and do quite meaty stuff in the interrupt handlers.
[...]
: 
: From ISO 9899, section 7.7.1.1: ``If the signal occurs other than as the
: result of calling the abort or raise function, the behavior is undefined
: if the signal handler calls any function in the standard library other
: than the signal function itself (with a first argument of the signal
: number corresponding to the signal tha caused the invocation of the
: handler) or refers to any object with static storage duration other than
: by assigning a value to a static storage duration variable of type
: volatile sig_atomic_t.''
[...]

In other words, the only asynchronous activity allowed to programs
with defined behavior is polling volatile atomic variables that are
set by signal handlers.  Thus far, no one has given me a reason for
prohibiting signal handlers from reading volatile atomic variables,
which is a common practice in interrupt handlers (even those written
in C/C++).

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