Date: Mon, 15 Jun 2009 22:25:47 +0100 (BST) From: Robert Watson <rwatson@FreeBSD.org> To: John Baldwin <jhb@freebsd.org> Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org, Colin Percival <cperciva@freebsd.org> Subject: Re: svn commit: r194262 - in head: include lib/libc/sys sys/compat/freebsd32 sys/kern tools/regression/file/closefrom Message-ID: <alpine.BSF.2.00.0906152223390.8936@fledge.watson.org> In-Reply-To: <200906151709.55435.jhb@freebsd.org> References: <200906152038.n5FKctaR001026@svn.freebsd.org> <4A36B3E2.7060309@freebsd.org> <200906151709.55435.jhb@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 15 Jun 2009, John Baldwin wrote:
> On Monday 15 June 2009 4:49:38 pm Colin Percival wrote:
>> John Baldwin wrote:
>>> One difference from other *BSD is that this closefrom() does not
>>> fail with any errors. In practice, while the manpages for NetBSD and
>>> OpenBSD claim that they return EINTR, they ignore internal errors from
>>> close() and never return EINTR. DFly does return EINTR, but for the common
>>> use case (closing fd's prior to execve()), the caller really wants all
>>> fd's closed and returning EINTR just forces callers to call closefrom() in
>>> a loop until it stops failing.
>>
>> Wouldn't it be better for portability if closefrom(2) is defined to return an
>> int, even if the value returned is always zero? Otherwise people who want to
>> write code which works on all BSDs end up having to do something like
>> #ifdef __FreeBSD__
>> closefrom(x);
>> #else
>> while (closefrom(x))
>> continue;
>> #endif
>
> Solaris returns void, so we just end up in their #ifdef vs the other.
> Also, Robert's belief is that the vast majority of existing code doesn't do
> a loop correctly, but instead just does a single call to closefrom(x). In
> that case, ignoring errors gives the best chance of working correctly.
To me, interrupting the loop on EINTR doesn't make much sense, as it means
applications would always use:
do {
ret = closefrom(x);
} while (ret < 0);
Since the desirable idiom is rarely "close until you hit one that EINTRs, in
which case abort but don't tell me which one it was". I find it equally
likely for other errno values sometimes returned -- EIO, etc. If you want to
close one file descriptor and reliably collect error-on-close, you must use
close(2). Non-deterministic file descriptor closing seems... unuseful.
Robert N M Watson
Computer Laboratory
University of Cambridge
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?alpine.BSF.2.00.0906152223390.8936>