On Sun, Feb 04, 2018 at 04:15:16PM +1100, Bruce Evans wrote:
> sig_atomic_t is no better than plain int.  This behaviour now makes complete
> sense.  It is just like the undefined behaviour with the ctype functions,
> except since we own terminate_wfd we can guarantee that it doesn't change
> while the handler is active (and is valid when the handler is entered).
> We could also use atomic ops.  However, the C standard doesn't require
> anything that we do to work (except maybe in C11, atomic ops might be
> explicitly or implicitly specifed to work for things like this).

Atomics are atomic WRT the signal handlers as well, the usual guarantees
of no torn writes and no out of air values on read hold.  Since FreeBSD
memory model, as documented in atomic(9), claims that naturally aligned
machine-native integer types are atomic without special declarations on
access, all guarantees for the handler accesses are already provided.

C11 also has a tool to ensure weaker than usual consistency guarantee,
only between the thread and a signal handler executing in the context of
the thread.  I do not see it useful in the discussed case.
svn-src-head@freebsd.org mailing list
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

Reply via email to