httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dean Gaudet <dgau...@arctic.org>
Subject Re: lingering_close performance idea
Date Mon, 10 Feb 1997 01:35:19 GMT
Actually I thought about processing pending closes before processing a
request and concluded it's way too hard -- 'cause the close processing
takes longer than "an instant".  So you can't do it while you have the
accept mutex, and you shouldn't do it after the accept()... it should
really come at the end while nobody is waiting on the child.

Yep it certainly can cause problems with delaying the read()s.
We definately have to build an fd_set, do a select() and appropriate
read()s every time we process pending closes.

It's too bad there's no way to pass a socket to another pid or we could
have a cleanup process. 

Dean

P.S. Hey are you telling me IRIX and linux aren't major?  This is
shattering my world-view.  stop! :)


On Sun, 9 Feb 1997, Marc Slemko wrote:

> 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