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>