|Reply to:||Hans-J. Boehm|
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.
When the processing of the abstract machine is interrupted by receipt of a signal, the values of objects
with type other than
are unspecified, and the value of any object not
of typethat is modified by the handler becomes undefined.
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. 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.