Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 4 Feb 2018 12:33:34 +0200
From:      Konstantin Belousov <kostikbel@gmail.com>
To:        Bruce Evans <brde@optusnet.com.au>
Cc:        Conrad Meyer <cem@freebsd.org>, src-committers <src-committers@freebsd.org>, svn-src-all@freebsd.org, svn-src-head@freebsd.org
Subject:   Re: svn commit: r327495 - head/usr.sbin/rpcbind
Message-ID:  <20180204103334.GC9536@kib.kiev.ua>
In-Reply-To: <20180204150751.V909@besplex.bde.org>
References:  <201801021725.w02HPDaj068477@repo.freebsd.org> <20180203232725.U1389@besplex.bde.org> <CAG6CVpXodjf7HfagpaY6K1t69a1jx37FRqvQq2acg5eT0r1Z-A@mail.gmail.com> <20180204150751.V909@besplex.bde.org>

next in thread | previous in thread | raw e-mail | index | archive | help
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.



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20180204103334.GC9536>