httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dean Gaudet <dgau...@arctic.org>
Subject Re: new acceptor logic.
Date Mon, 22 Feb 1999 16:55:24 GMT


On Fri, 19 Feb 1999, Ryan Bloom wrote:

> A while back, I suggested we use a file descriptor queue of length N,
> where N is the number of worker thread, to handle serving requests.
> Basically, an acceptor thread would get the request, and place the new
> socket decriptor in the fdqueue, where a worker thread would wake up, and
> serve the reqeust.
> 
> We implemented this, and found a nasty bug in the logic.  The acceptor
> queue is fast.  So fast, that the inital process never relinquishes the
> accept_mutex loing enough for another process to grab it.  So, what
> happens is that if I connect to the server, and have all of my server busy
> serving long-lived requests, the parent process spawns a new server that
> never does the accepting, and because my fdqueue is currently empty (all
> the socket's that were in there have been removed and are being served
> currently, my accept thread conitnues to accept new connections, putting
> the new socket in the queue.  If none of the original N requests is
> finished for five minutes, the new request isn't handled for five minutes.
> And we don't move onto the next process until the fdqueue has been filled
> for the second time.
> 
> This is bad.
> 
> So, here is the new solution for everybodies critique.  Have the fdqueue
> be dyanmic in length.  The fdqueue is always as large as the number of
> idle worker threads.  If the acceptor has no place to put new sockets, he
> goes to sleep, and another process will take over.
> 
> Thoughts?

I sent you this in private mail... but figure I'll repeat it here for
others -- I don't see the point in having an acceptor thread.  What's
wrong with doing the same thing 1.x does in processes?  Just let one
worker into the select/accept loop.  If there are no workers available
then no accept will be performed... you don't have to add any extra logic
to handle that.

Or pay one worker per socket -- let multiple be in accept, just on
different sockets.  If folks have less than busy sockets they'll be paying
one less than busy thread... but little extra cpu otherwise.

Either of these reduce context switches.

Dean



Mime
View raw message