--k+w/mQv8wyuph6w0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Mon, Jan 05, 2004 at 01:38:49AM +0100, mouss wrote:
> Matt Thomas wrote:
>=20
> >
> >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=
=20
> >for validity.
>=20
> well, I originally done this on fcntl but then changed my mind after=20
> receiving the following argument (from G.A. Drosihn):
>=20
> "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=
=20
how things work.

Also, I don't think we really want to close fd, the one we operate on, in=
=20
this call. So we really should NOT operate on the 1st parameter.

> so it's still debatable...
>=20
> PS. The aix manpage for fcntl is incorrect with this respect (moreover,=
=20
> it says fcntl operates on the _open_ file descriptor. not sure, f_closem=
=20
>  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=
=20
> >highest opened fd.
>=20
> 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. :-)

> >[snip]
> Ok, I'll look at the fcntl variant too.
>=20
> While I am at it, what should the call return? I thought returning EBADF=
=20
> 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=
=20
> 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=
=20
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.

Take care,

Bill

--k+w/mQv8wyuph6w0
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (NetBSD)

iD8DBQE/+bWJWz+3JHUci9cRAgNjAJ0ci9cXBkJA16yfpNr+3ucgkDtNowCcDVtQ
oZJ0espfq9fIG0si2nCMowY=
=RPBi
-----END PGP SIGNATURE-----

--k+w/mQv8wyuph6w0--