On Sun, 4 Feb 2018, Konstantin Belousov wrote:
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's precise wording is:
[for async signals] the behavior is undefined if the signal handler
refers to any object with static or thread storage duration that
is not a lock-free atomic object other than by assigning a value
to an object declared as volatile sig_atomic_t
i.e., the same as in C99 except the behaviour is not specifically undefined
for accesses to lock-free atomic objects.
Do we document atomics in userland? C11 atomics are too hard for me.
"lock-free atomic object" is a technical term and I don't know of any
userland documentation that associates this term with naive ideas of
atomics. atomic(9) doesn't mention this either.
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.
Is that just a check for the case if !async signals (ones that are the
result of raise() and abort()?).
Bruce
_______________________________________________
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
