Mailing-List: contact dev-help@apr.apache.org; run by ezmlm
Precedence: bulk
Message-ID: <3FD5E723.9020706@attglobal.net>
Date: Tue, 09 Dec 2003 10:15:47 -0500
From: Jeff Trawick <trawick@attglobal.net>
Reply-To: trawick@attglobal.net
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US;
 rv:1.5) Gecko/20031007
MIME-Version: 1.0
To: dev@httpd.apache.org, dev@apr.apache.org
Subject: Apache MPMs comparing new fds with FD_SETSIZE, APR's ability to wait
 for i/o on socket
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Currently when Apache httpd accepts a new connection via APR, it compares the 
fd with FD_SETSIZE and bombs if fd >= FD_SETSIZE.

The limited value of this check is on platforms such as OS X < 10.3 with no 
poll(), where APR has to use select().  Unfortunately, use 1K threads with 
worker MPM on Solaris or some other platform with relatively small *default* 
FD_SETSIZE and you'll start hitting meaningless FD_SETSIZE errors before you 
get the 1K threads busy talking to clients.  (APR doesn't use select() on 
Solaris anyway, so the FD_SETSIZE check is not helpful.)

For APR 1.0, I think it would be better for APR to handle this to the greatest 
extent so that APR apps don't have to worry about whether or not APR uses select().

APR responsibility:
   apr_accept()
     if new fd >= FD_SETSIZE and platform uses select, close new fd and
       return some new error code that says APR can't handle the fd
   apr_strerror()
     provide reasonable error string for the new error code
   btw, this extends to the creation of pipes too...

app responsibility:
   if app wants to consider this new APR error code fatal, then check for it;
   any existing logic to log the meaning of the error using apr_strerror() will
   do something reasonable

(alternate solution: don't do a check at object creation time (accept(), 
pipe()) but wait until we really do the select() and return the error then; app 
may never do I/O operations that require select() to be called)

Meanwhile, APR still has the potential to work better on platforms where 
select() is used.  One possibility is to raise FD_SETSIZE (builder can already 
do this via CPPFLAGS), but this starts killing FD_ZERO performance if 
FD_SETSIZE gets really big, so it would be helpful for the APR code calling 
select() to zero out just enough of the fd set as necessary.  Another 
possibility is to use an alternate set of macros which always support a 
reasonable value (e.g., 8K).

comments?