🚀 go-pugleaf

In article <4ebptg$frt@galaxy.ucr.edu> thp@cs.ucr.edu (Tom Payne)
writes:

> : 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++).

Correct.  In practice, I cannot conceive of an implementation where
writing something would be atomic, but reading it wouldn't.  On the
other hand, read/modify/write will frequently not be atomic.  And why
else might you want to read an object in a signal handler, if not to
modify it?

-- 
James Kanze           (+33) 88 14 49 00          email: kanze@gabi-soft.fr
GABI Software, Sarl., 8 rue des Francs Bourgeois, 67000 Strasbourg, France
Conseils, études et réalisations en logiciel orienté objet --
              -- A la recherche d'une activité 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. ]