httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ryan Bloom <...@raleigh.ibm.com>
Subject new acceptor logic.
Date Fri, 19 Feb 1999 18:17:56 GMT

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?

Ryan

_______________________________________________________________________
Ryan Bloom		rbb@raleigh.ibm.com
4205 S Miami Blvd	
RTP, NC 27709		It's a beautiful sight to see good dancers 
			doing simple steps.  It's a painful sight to
			see beginners doing complicated patterns.	


Mime
View raw message