read/write sig_atomic_t

17 views
Skip to first unread message

Hallvard B Furuseth

unread,
Jan 27, 2005, 3:29:43 AM1/27/05
to
Why does the standard not guarantee that a signal handler can read
a volatile sig_atomic_t (7.14.1.1p5), when it does guarantee that
access to sig_atomic_t access is atomic (7.14p2)?

7.14p2 sig_atomic_t which is the (possibly volatile-qualified)
integer type of an object that can be accessed as an atomic
entity, even in the presence of asynchronous interrupts.

7.14.1.1p5 behavior is undefined if the signal handler refers to
any object with static storage duration other than by assigning
a value to an object declared as volatile sig_atomic_t,

Is there a real possibility that a read in a signal handler could break
something? I can think of one such scenario, but it violates 7.14p2:

There are no machine instructions for atomic sig_atomic_t access. If
the access is interrupted, it is restarted or canceled as appropriate
when the signal handler returns. Thus, the signal handler could see
a partially written value, but the interrupted function could not.

Implementing it would be pretty yucky, too:-)

--
Hallvard

Douglas A. Gwyn

unread,
Feb 1, 2005, 4:34:29 PM2/1/05
to
Hallvard B Furuseth wrote:
> Why does the standard not guarantee that a signal handler can read
> a volatile sig_atomic_t ...?

Because signal handlers suck, and it was hard enough getting
consensus on adding "setting a flag variable" to the small
list of things that a s.c. program is allowed to do within
a signal handler.

Reply all
Reply to author
Forward
0 new messages