Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
Date: Tue, 6 Jan 2004 10:14:45 -0500
From: Glenn <gs-apache-dev@gluelogic.com>
To: dev@httpd.apache.org
Subject: Re: FD_SETSIZE comparison
Message-ID: <20040106151445.GA26453@netspace.org>
References: <3FFACBFB.9000104@web.turner.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <3FFACBFB.9000104@web.turner.com>
User-Agent: Mutt/1.4.1i

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