Doc. No.: | WG21/N2547 J16/08-0057 |
---|---|
Revision of: | WG21/N2459 J16/07-0329 |
Date: | 2008-02-27 |
Reply to: | Hans-J. Boehm |
Phone: | +1-650-857-3406 |
Email: | Hans.Boehm@hp.com |
The first of the applications listed above is already supported by N2427. The second cannot really be addressed by the C++ standard. Here we propose to allow the use of atomics in signal handlers, to the extent that is under control of the C++ standard.
Our intent is to allow full use of atomic operations on atomic object x in a signal handler whenever atomic_is_lock_free(x) or x.is_lock_free() is true. For example, in a Posix environment, these operations are intended to be async-signal-safe. But that is clearly beyond the scope of this standard.
1.9p7:
When the processing of the abstract machine is interrupted by receipt of a signal, the values of objectswith type other thanwhich are neithervolatile std::sig_atomic_t
are unspecified, and the value of any object not
- of type
volatile std::sig_atomic_t
, nor- a lock-free atomic object (29.2 [atomics.lockfree])
of typein either of these two categories that is modified by the handler becomes undefined.volatile std::sig_atomic_t
18.8p6
The common subset of the C and C++ languages consists of all declarations, definitions, and expressions that may appear in a well formed C++ program and also in a conforming C program. A POF (plain old function) is a function that uses only features from this common subset, and that does not directly or indirectly use any function that is not a POF, except that it may use functions defined in clause 29[atomics] that are not member functions. All signal handlers shall have C linkage. A POF that could be used as a signal handler in a conforming C program does not produce undefined behavior when used as a signal handler in a C++ program. The behavior of any other function used as a signal handler in a C++ program is implementation-defined.
The second change is essentially a stopgap measure, which we expect to become redundant when atomics are accepted into the C standard. It is not clear that omitting the second change would cause real problems, though it seems a bit safer to include it.