From: Jim Jagielski <jim@jaguNET.com>
Message-Id: <199702120222.VAA22330@shado.jaguNET.com>
Subject: Re: [PATCH] lingering_close performance improvement
To: new-httpd@hyperreal.com
Date: Tue, 11 Feb 1997 21:22:13 -0500 (EST)
In-Reply-To: <33012590.15FB7483@topsail.org> from "Chuck Murcko" at Feb 11,
 97 09:06:08 pm
Content-Type: text
Sender: new-httpd-owner@apache.org
Precedence: bulk
Reply-To: new-httpd@hyperreal.com

Chuck Murcko wrote:
> 
> Roy T. Fielding wrote:
> > 
> > >I will not object to your committing it, but ask that everyone keep in
> > >mind that this may not be what we end up shipping in 1.2 if something
> > >better comes up.
> > 
> > Yes, absolutely -- I just want the testing to be based on what we have now
> > instead of what we had last week.
> > 
> > >What do you think of Dean's suggestion of keeping a history of sockets
> > >that are lingering and then just going through them each time through the
> > >main loop before we accept a new request?  Assuming, of course, that it
> > >can be implemented cleanly which is not necessarily a valid assumption.
> > 
> > That is basically what RST's multithreaded code does, and I think it is
> > a much better idea than what we are currently doing.  I just don't know
> > how to do it without introducing multithreading, etc.
> > 
> True, but this is really the only correct (and nonkludgey) way to deal
> with pipelined request errors, isn't it? We'll need this anyway, since I
> don't think Henrik's tests ran on really crappy connections.
> 

Unless we are fully multithreaded, doing this really puts a hurting
on those systems with limited numbers of fd's :/


-- 
====================================================================
      Jim Jagielski            |       jaguNET Access Services
     jim@jaguNET.com           |       http://www.jaguNET.com/
                  "Not the Craw... the CRAW!"