Date: Fri, 26 Feb 1999 23:01:02 -0500 (EST)
From: Ryan Bloom <rbb@raleigh.ibm.com>
To: new-httpd@apache.org
Subject: Re: new acceptor logic.
In-Reply-To: <Pine.LNX.3.96dg4.990226101857.21889M-100000@twinlark.arctic.org>
Message-ID: <Pine.A41.4.05.9902262245130.15726-100000@webdev7.raleigh.ibm.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: new-httpd-owner@apache.org
Precedence: bulk
Reply-To: new-httpd@apache.org

> OK, we can probably agree that situations where there isn't always a new
> connection ready to be accepted (or fd already accepted) when a worker
> thread finishes a previous connection are not interesting -- the load
> isn't high enough to saturate the server, so sleeping we don't care about.

Agreed.

> Am I still missing something?

I'm not sure we are talking about the same case.  I agree, your method
will work better than mine when we are only accepting on one socket, and I
do plan to implement this at some point.  However, what about multiple
sockets.  I see two options:

1)  Using a counting mutex, we let N threads in to accept on N sockets.
Inside the mutex, we grab another mutex and look for a socket to listen on
in an array of sockets.  When we find one, we update the array of
sockets.  Release the mutex.  Accept on the socket and serve the request.

2)  All Threads block on one mutex.  When they get the mutex, they do a
select to find a socket that has data coming in.  Do the accept, serve the
request.

On every system we have looked at, select is a very expensive operation,
and causes a performance hit.  We haven't done any real acurate
benchmarking yet, but that is in the plan.

I will implement both of these as soon as I have a chance, and then we can
do some benchmarking to determine the best method.  I believe we have to
compare algorithms that will accept connections on multiple sockets.

Ryan