Subject: Re: implementing closeall via a syscall
To: mouss <email@example.com>
From: Bill Studenmund <firstname.lastname@example.org>
Date: 01/05/2004 11:05:45
Content-Type: text/plain; charset=us-ascii
On Mon, Jan 05, 2004 at 01:38:49AM +0100, mouss wrote:
> Matt Thomas wrote:
> >I'd prefer to follow prior art so i think the AIX fcntl FCLOSEM is=20
> >preferrable to me. It's not that hard to make fcntl to not check the fd=
> >for validity.
> well, I originally done this on fcntl but then changed my mind after=20
> receiving the following argument (from G.A. Drosihn):
> "The description for fcntl says the first parameter is:
> a descriptor to be operated on by 'cmd' as
> described below.
> For the proposed F_CLOSEM command, it does not operate on the
> GIVEN fd, it operates on a whole bunch of OTHER fd's. This
> means that a program which calls fcntl with a cmd-argument
> which is different than the programmer thinks is being passed
> could cause some pretty painful-to-debug errors in sections of
> the program which have nothing to do with the section that has
> the bug."
I'd say shove the arguement. :-) If the situation merits it, we can change=
how things work.
Also, I don't think we really want to close fd, the one we operate on, in=
this call. So we really should NOT operate on the 1st parameter.
> so it's still debatable...
> PS. The aix manpage for fcntl is incorrect with this respect (moreover,=
> it says fcntl operates on the _open_ file descriptor. not sure, f_closem=
> cares about the fd being open).
Well, we can get things right in our man page. Like note that we don't=20
touch the 1st parameter. :-)
> >An alternative might be add an F_MAXFD to fcntl which would return the=
> >highest opened fd.
> yes, but this still requires multiple close() on probably closed=20
> descriptors, which is a bit suboptimal, given that we can have it done=20
> in the kernel via similar means.
I like this idea better (the fcntl that does it all). Also, following=20
prior art when it's reasonable seems like a good thing. Who knows, it=20
might become POSIX at some future date. :-)
> Ok, I'll look at the fcntl variant too.
> While I am at it, what should the call return? I thought returning EBADF=
> if the arg is too large and 0 otherwise. Solaris closefrom() returns=20
> void (since it just calls close() on fds known to be open (if we ignore=
> the race condition).
Also, what do we do if the 1st parameter is in the to-be-closed range? I=20
don't think we should close it as that's a state transition I don't really=
want in the fcntl code. :-) So do we close the other nodes and just skip=20
the 1st parameter, or do we return an error and do nothing?
> Also, what if it fails (NFS timeout for instance)?
Thinking about the code paths that will call this, I don't think we can=20
really do any error recovery in this case, so ignore the error. The main=20
thing we want to do is make it so a newly-execed program won't see the=20
file descriptor, and that can be done even if there's an NFS timeout.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (NetBSD)
-----END PGP SIGNATURE-----