From owner-svn-src-all@freebsd.org Sun Feb 4 21:02:16 2018 Return-Path: Delivered-To: svn-src-all@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 EF8DDEC1C0F; Sun, 4 Feb 2018 21:02:15 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 772CB724BC; Sun, 4 Feb 2018 21:02:15 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id w14L27LZ022191 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 4 Feb 2018 23:02:10 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua w14L27LZ022191 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id w14L27Pv022190; Sun, 4 Feb 2018 23:02:07 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sun, 4 Feb 2018 23:02:07 +0200 From: Konstantin Belousov To: Bruce Evans Cc: Conrad Meyer , src-committers , svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r327495 - head/usr.sbin/rpcbind Message-ID: <20180204210207.GF9536@kib.kiev.ua> References: <201801021725.w02HPDaj068477@repo.freebsd.org> <20180203232725.U1389@besplex.bde.org> <20180204150751.V909@besplex.bde.org> <20180204103334.GC9536@kib.kiev.ua> <20180205064120.K996@besplex.bde.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180205064120.K996@besplex.bde.org> User-Agent: Mutt/1.9.3 (2018-01-21) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Feb 2018 21:02:16 -0000 On Mon, Feb 05, 2018 at 07:53:03AM +1100, Bruce Evans wrote: > 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 atomics are not exactly same as FreeBSD atomics, and they are implemented by different API. Our atomic(9) API works same in kernel and in userland. A (C11) lock-free atomic is the object for which the atomic_is_lock_free() returns true. > > > 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()?). Probably it was too obscure. I mean atomic_signal_fence().