You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@apr.apache.org by Jeff Trawick <tr...@attglobal.net> on 2004/01/27 00:23:15 UTC
[PATCH] don't overlay storage selecting on big fd
FD_SET is rather unfriendly if you give it a file descriptor that is >=
FD_SETSIZE. It will overlay storage.
Exception: Windows uses an array[FD_SETSIZE] of handles, so the value of
individual handles is irrelevant. I don't know what other exceptions
there might be.
Any comments? Yeah, the error code sucks. APR_ENOPOLL? APR_ENOSOCKET?
Anybody running a super-threaded httpd MPM on a box without poll()?
Apache httpd's MPMs for Unix will stop bailing out for client
connections using a socket fd >= FD_SETSIZE. They do it now just in
case the platform has no poll(), but it is doubtful that more than a
handful of people really need that check, and hopefully an apr patch
like this one will be sufficient to convince such people that they
should lower the threads or otherwise reduce the fds open in the
process. (They had to do that anyway when httpd performed the check.)
Re: [PATCH] don't overlay storage selecting on big fd
Posted by Jeff Trawick <tr...@attglobal.net>.
gregames@apache.org wrote:
> Jeff Trawick wrote:
>
>> FD_SET is rather unfriendly if you give it a file descriptor that is
>> >= FD_SETSIZE. It will overlay storage.
>
>
>> Any comments? Yeah, the error code sucks. APR_ENOPOLL? APR_ENOSOCKET?
>
>
> What's wrong with APR_EBADF? That give me a good hint of what the
> problem is
> without having to grep/Google/look stuff up.
Be happy, that's the way the code is today ;) I'm not sure what you'd have to
look up though since a good app would be printing the output of apr_strerror in
addition to the numeric error code, so the issue becomes whether something like
(9)can't read from socket: an invalid file descriptor was specified
is acceptable when
(20095)can't read from socket: an APR limitation on the range of file
descriptors was encountered
is possible. The latter is clearly not the insidious type of bug where one
thread mucks with some other thread's file descriptors (perhaps due to double
close), whereas the former allows several possible explanations.
(I have no plans to take action, since the only objection I've seen is an
objection to my objection to the code I committed :) )
Re: [PATCH] don't overlay storage selecting on big fd
Posted by gr...@apache.org.
Jeff Trawick wrote:
> FD_SET is rather unfriendly if you give it a file descriptor that is >=
> FD_SETSIZE. It will overlay storage.
> Any comments? Yeah, the error code sucks. APR_ENOPOLL? APR_ENOSOCKET?
What's wrong with APR_EBADF? That give me a good hint of what the problem is
without having to grep/Google/look stuff up.
Greg
> +#if !defined(WIN32) /* socket sets handled with array of handles */
> + if (fd >= FD_SETSIZE) {
> + /* XXX invent new error code so application has a clue */
> + return APR_EBADF;
> + }