Re: Is sendfile all that sexy?

[dean gaudet]

On Tue, 16 Jan 2001, David L. Parsley wrote:

> Felix von Leitner wrote:
> > >   close (0);
> > >   close (1);
> > >   close (2);
> > >   open ("/dev/console", O_RDWR);
> > >   dup ();
> > >   dup ();
> >
> > So it's not actually part of POSIX, it's just to get around fixing
> > legacy code? ;-)

it's part of POSIX.

> This makes me wonder...
>
> If the kernel only kept a queue of the three smallest unused fd's, and
> when the queue emptied handed out whatever it liked, how many things
> would break?  I suspect this would cover a lot of bases...

apache-1.3 relies on the open-lowest-numbered-free-fd behaviour... but
only as a band-aid to work around other broken behaviours surrounding
FD_SETSIZE.

when opening the log files, and listening sockets apache uses
fcntl(F_DUPFD) to push them all higher than fd 15.  (see ap_slack)  some
sites are configured in a way that there's thousands of log files or
listening fds (both are bogus configs in my opinion, but hey, let the
admin shoot themself).

this generally leaves a handful of low numbered fds available.  this
pretty much protects apache from broken libraries compiled with small
FD_SETSIZE, or which otherwise can't handle big fds.  libc used to be just
such a library because it used select() in the DNS resolver code.  (a libc
guru can tell you when this was fixed.)

it also ensures that the client fd will be low numbered, and lets us be
lazy and just use select() rather than do all the config tests to figure
out which OSs support poll().

it's all pretty gross... but then select() is pretty gross and it's
essentially the bug that necessitated this.

(solaris also has a stupid FILE * limitation that it can't use fds > 255
in a FILE * ... which breaks even more libraries than fds >= FD_SETSIZE.)

-dean