svn commit: r327495 - head/usr.sbin/rpcbind

[Bruce Evans]

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