From owner-svn-src-head@freebsd.org Sun Feb 4 20:53:15 2018 Return-Path: Delivered-To: svn-src-head@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 65064EF0F95; Sun, 4 Feb 2018 20:53:15 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail109.syd.optusnet.com.au (mail109.syd.optusnet.com.au [211.29.132.80]) by mx1.freebsd.org (Postfix) with ESMTP id DB9B971DC4; Sun, 4 Feb 2018 20:53:14 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from [192.168.0.102] (c110-21-101-228.carlnfd1.nsw.optusnet.com.au [110.21.101.228]) by mail109.syd.optusnet.com.au (Postfix) with ESMTPS id 6D8C1D6CBA5; Mon, 5 Feb 2018 07:53:05 +1100 (AEDT) Date: Mon, 5 Feb 2018 07:53:03 +1100 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Konstantin Belousov cc: Conrad Meyer , src-committers , svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r327495 - head/usr.sbin/rpcbind In-Reply-To: <20180204103334.GC9536@kib.kiev.ua> Message-ID: <20180205064120.K996@besplex.bde.org> References: <201801021725.w02HPDaj068477@repo.freebsd.org> <20180203232725.U1389@besplex.bde.org> <20180204150751.V909@besplex.bde.org> <20180204103334.GC9536@kib.kiev.ua> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Optus-CM-Score: 0 X-Optus-CM-Analysis: v=2.2 cv=DIX/22Fb c=1 sm=1 tr=0 a=PalzARQSbocsUSjMRkwAPg==:117 a=PalzARQSbocsUSjMRkwAPg==:17 a=kj9zAlcOel0A:10 a=vm9bT6jSjgWHGVm1leUA:9 a=CjuIK1q_8ugA:10 X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Feb 2018 20:53:15 -0000 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