From owner-freebsd-standards@freebsd.org Sun Feb 25 13:51:30 2018 Return-Path: Delivered-To: freebsd-standards@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 DE697F2F645; Sun, 25 Feb 2018 13:51:29 +0000 (UTC) (envelope-from kib@freebsd.org) 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 4DC417DD7E; Sun, 25 Feb 2018 13:51:29 +0000 (UTC) (envelope-from kib@freebsd.org) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id w1PDpCuk031025 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 25 Feb 2018 15:51:15 +0200 (EET) (envelope-from kib@freebsd.org) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua w1PDpCuk031025 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id w1PDpBjT031024; Sun, 25 Feb 2018 15:51:11 +0200 (EET) (envelope-from kib@freebsd.org) X-Authentication-Warning: tom.home: kostik set sender to kib@freebsd.org using -f Date: Sun, 25 Feb 2018 15:51:11 +0200 From: Konstantin Belousov To: Stefan Blachmann Cc: Eitan Adler , FreeBSD Hackers , FreeBSD Standards , cem@freebsd.org Subject: Re: Marking select(2) as restrict Message-ID: <20180225135111.GO94212@kib.kiev.ua> References: <20180221185920.GA94212@kib.kiev.ua> <23181.50488.186767.579361@khavrinen.csail.mit.edu> <20180221201002.GC94212@kib.kiev.ua> <23181.54825.511195.393054@khavrinen.csail.mit.edu> <20180222212746.GB58772@stack.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.3 (2018-01-21) X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home X-BeenThere: freebsd-standards@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Standards compliance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Feb 2018 13:51:30 -0000 On Sun, Feb 25, 2018 at 06:52:55AM +0100, Stefan Blachmann wrote: > The Linux manual pages do not mention restrict for select(). > glibc select() itself returns just ENOSYS(), if there is no alias for select(). > > So I guess what actually gets called is this: > https://github.com/udp/freebsd-libc/blob/master/sys/select.c#L48 > Which in turn appears to call __sys_select: > https://github.com/udp/freebsd-libc/blob/master/include/libc_private.h#L346 > See also: > https://lists.freebsd.org/pipermail/freebsd-questions/2007-August/154906.html > > If I understand correctly, the *only* place that defines the > optimizations actually being done is the static functions itself: > https://github.com/freebsd/freebsd/blob/master/lib/libthr/thread/thr_syscalls.c#L487 No, you do not understand this correctly. Select(2) implementation is in kernel and cannot be affected by the userspace prototype change. It is the caller of select(2) which might be optimized unexpectedly when select claims that its arguments cannot be aliased. The use of restrict in the glibc prototype would be a good argument if clang on glibc were not a rare combination. > > So maybe the actual prototypes being used for the > functions for which the interpose array is used are irrelevant: > https://github.com/freebsd/freebsd/blob/master/lib/libthr/thread/thr_syscalls.c#L642 > > I not yet found out which functions are actually weakly aliased in, > but I could imagine that adding the restrict keyword to the prototypes > of the functions listed there, is possibly only > of cosmetical importance, without any actual effect. > If this is correct, one could be "Posix compliant" without causing any > disruptive "optimization" :) > > Have a nice Sunday! > Stefan > > > P.S.: Maybe it would be better to avoid adding the restrict keyword in the > __thr_select() function itself mentioned above, as Linux' select > function seems to have no restrict: > https://github.com/torvalds/linux/blob/master/fs/select.c#L1262 > https://github.com/torvalds/linux/blob/master/fs/select.c#L599 > > > On 2/25/18, Eitan Adler wrote: > > On 24 February 2018 at 10:55, Conrad Meyer wrote: > >> On Sat, Feb 24, 2018 at 10:35 AM, Eitan Adler > >> wrote: > >>> After this entire thread here is the summary. If I've misrepresented > >>> you here please let me know. > >>> ... > >>> > >>> kib@ - no benefit; concerned fallout could be hard to observe > >>> cem@ - concerned about warnings > >> > >> Consider me a +1 to kib@. I did not voice those concerns explicitly > >> in earlier email because kib did already and I didn't anticipate you > >> would ignore him. > > > > I am not ignoring him. As I stated above I do not believe fallout is > > likely since most other major libc implementations have already done > > this: > > > > glibc: already done - > > https://github.com/bminor/glibc/blob/master/misc/sys/select.h#L101 > > openbsd: already done > > https://github.com/openbsd/src/blob/master/sys/sys/select.h#L128 > > dragonflyBSD: alredy done: > > https://github.com/dragonflybsd/dragonflybsd/blob/master/sys/sys/select.h#L50 > > netbsd: already done: > > https://github.com/NetBSD/src/blob/trunk/sys/sys/select.h#L69 > > > > As a further check I went through the search results on github for > > select() and did not see any failures in the top few pages. > > > > -- > > Eitan Adler > > _______________________________________________ > > freebsd-hackers@freebsd.org mailing list > > https://lists.freebsd.org/mailman/listinfo/freebsd-hackers > > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > > > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org"