httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marc Slemko <ma...@znep.com>
Subject Re: lingering_close performance idea
Date Mon, 10 Feb 1997 01:15:17 GMT
On Sun, 9 Feb 1997, Dean Gaudet wrote:

> Wouldn't it be possible to delay our processing of the lingering_close,
> and allow the child to be ready to serve more requests by simply *NOT*
> closing the socket immediately.  Do the shutdown(sd, 1), add it to a list
> of sockets waiting to be close()d along with a time(0) stamp.  Then clean
> up and return to the accept() phase.  Before going into the accept mutex,
> check the list of pending sockets, compare against time(0), deal with
> close processing on any required.  Then do the accept(). 
> 
> Essentially this is a multithreaded solution. 

How about we just make 1.2 entirely mulithreaded and then not worry about
it?  <g>

Interesting idea.  I am uncertain about all of the interactions, though. 
The data the client is sending could possibly not be read for several
minutes if servicing a long request.  This could end up with even more
connections in FIN_WAIT_2 hanging around and could do bad things to the
client.  The implementation shouldn't be overly difficult if a few
assumptions, such as that it is enough to only check after/before (same
thing) processing a request are made.  You can't forget the read bit of
lingering_close; well, perhaps you can but not without some more thought.

I'll have to look at it in more detail.

> 
> For sites with problems allocating enough descriptors there needs to be a
> MaxPendingCloseSockets directive.

This shouldn't result in many more than having a server in lingering_close
and having another servince the new request.

> 
> BTW, why the heck is the accept mutex needed for every single major OS,
> didn't any of them get it right?  What goes wrong without it? 

Naw, that's just you thinking IRIX and Linux are all the major OSes.  <g>

(no, I don't know why...)


Mime
View raw message