You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Brian Akins <ba...@web.turner.com> on 2004/01/06 15:53:47 UTC
FD_SETSIZE comparison
Call me stupid, put why in various places does Apache do things like this:
if (csd >= FD_SETSIZE) {
ap_log_error(APLOG_MARK, APLOG_WARNING, 0, NULL,
"new file descriptor %d is too large; you probably
need "
"to rebuild Apache with a larger FD_SETSIZE "
"(currently %d)",
csd, FD_SETSIZE);
apr_socket_close(sock);
return;
}
On linux, at least, FD_SETSIZE is fairly low (1024), yet the actually
max file descriptors can be much, much higher (we have thousands per
process with squid).
Is this just not true elsewhere? Can someone explain?
--
Brian Akins
Senior Systems Engineer
CNN Internet Technologies
Re: FD_SETSIZE comparison
Posted by Jeff Trawick <tr...@attglobal.net>.
Brian Akins wrote:
> Call me stupid, put why in various places does Apache do things like this:
> if (csd >= FD_SETSIZE) {
> ap_log_error(APLOG_MARK, APLOG_WARNING, 0, NULL,
> "new file descriptor %d is too large; you probably
> need "
> "to rebuild Apache with a larger FD_SETSIZE "
> "(currently %d)",
> csd, FD_SETSIZE);
> apr_socket_close(sock);
> return;
> }
>
> On linux, at least, FD_SETSIZE is fairly low (1024), yet the actually
> max file descriptors can be much, much higher (we have thousands per
> process with squid).
If APR uses select() to implement send/recv/connect timeouts, some code
some where needs to check for FD_SETSIZE to prevent that select() logic
from blowing up (it could even overlay storage).
But APR doesn't use select() on most boxes since poll() is pretty
standard nowadays. The plan is to yank these checks from Apache 2.1-dev
(which uses APR 1.0) and change APR 1.0 to implement the check only on
the dwindling set of platforms where select() is used.
Re: FD_SETSIZE comparison
Posted by Glenn <gs...@gluelogic.com>.
On Tue, Jan 06, 2004 at 09:53:47AM -0500, Brian Akins wrote:
> Call me stupid, put why in various places does Apache do things like this:
> if (csd >= FD_SETSIZE) {
> ap_log_error(APLOG_MARK, APLOG_WARNING, 0, NULL,
> "new file descriptor %d is too large; you probably
> need "
> "to rebuild Apache with a larger FD_SETSIZE "
> "(currently %d)",
> csd, FD_SETSIZE);
> apr_socket_close(sock);
> return;
> }
>
> On linux, at least, FD_SETSIZE is fairly low (1024), yet the actually
> max file descriptors can be much, much higher (we have thousands per
> process with squid).
>
> Is this just not true elsewhere? Can someone explain?
You can use file descriptors up to OPEN_MAX.
However, you can only select() on fds < FD_SETSIZE.
That is a limitation of select() because of the memory size
of the fd_set typedef (based on FD_SETSIZE).
It is not a limitation of poll(), or other mechanisms like
kqueue, sys_epoll, or /dev/poll.
Cheers,
Glenn
Re: FD_SETSIZE comparison
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Perhaps this is none of Apache's business, but should be a very specific
result from the various apr_poll setup functions that invoke select()?
Bill
At 08:53 AM 1/6/2004, Brian Akins wrote:
>Call me stupid, put why in various places does Apache do things like this:
>if (csd >= FD_SETSIZE) {
> ap_log_error(APLOG_MARK, APLOG_WARNING, 0, NULL,
> "new file descriptor %d is too large; you probably need "
> "to rebuild Apache with a larger FD_SETSIZE "
> "(currently %d)",
> csd, FD_SETSIZE);
> apr_socket_close(sock);
> return;
> }
>
>On linux, at least, FD_SETSIZE is fairly low (1024), yet the actually max file descriptors can be much, much higher (we have thousands per process with squid).
>
>
>Is this just not true elsewhere? Can someone explain?
>
>--
>Brian Akins
>Senior Systems Engineer
>CNN Internet Technologies