[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200515160342.GE23230@ZenIV.linux.org.uk>
Date: Fri, 15 May 2020 17:03:42 +0100
From: Al Viro <viro@...iv.linux.org.uk>
To: Nate Karstens <nate.karstens@...min.com>
Cc: Jeff Layton <jlayton@...nel.org>,
"J. Bruce Fields" <bfields@...ldses.org>,
Arnd Bergmann <arnd@...db.de>,
Richard Henderson <rth@...ddle.net>,
Ivan Kokshaysky <ink@...assic.park.msu.ru>,
Matt Turner <mattst88@...il.com>,
"James E.J. Bottomley" <James.Bottomley@...senpartnership.com>,
Helge Deller <deller@....de>,
"David S. Miller" <davem@...emloft.net>,
Jakub Kicinski <kuba@...nel.org>,
Eric Dumazet <edumazet@...gle.com>,
David Laight <David.Laight@...lab.com>,
linux-fsdevel@...r.kernel.org, linux-arch@...r.kernel.org,
linux-alpha@...r.kernel.org, linux-parisc@...r.kernel.org,
sparclinux@...r.kernel.org, netdev@...r.kernel.org,
linux-kernel@...r.kernel.org, Changli Gao <xiaosuo@...il.com>
Subject: Re: [PATCH v2] Implement close-on-fork
On Fri, May 15, 2020 at 10:23:17AM -0500, Nate Karstens wrote:
> This functionality was approved by the Austin Common Standards
> Revision Group for inclusion in the next revision of the POSIX
> standard (see issue 1318 in the Austin Group Defect Tracker).
It penalizes every call of fork() in the system (as well as adds
an extra dirtied cacheline on each socket()/open()/etc.), adds
memory footprint and complicates the API. All of that - to deal
with rather uncommon problem that already has a portable solution.
As for the Austin Group, the only authority it has ever had derives
from consensus between existing Unices. "Solaris does it, Linux and
*BSD do not" translates into "Austin Group is welcome to take a hike".
BTW, contrary to the lovely bit of misrepresentation in that
thread of theirs ("<LWN URL> suggests that" != "someone's comment
under LWN article says it _appears_ that"), none of *BSD do it.
IMO it's a bad idea.
NAKed-by: Al Viro <viro@...iv.linux.org.uk>
Powered by blists - more mailing lists