Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
Received-SPF: neutral (hermes.apache.org: local policy)
Date: Fri, 15 Apr 2005 13:15:56 -0700
From: Justin Erenkrantz <justin@erenkrantz.com>
To: dev@httpd.apache.org
Subject: Re: AP_MODE_EATCRLF considered indigestible
Message-ID: <20050415201555.GH29417@scotch.ics.uci.edu>
Mail-Followup-To: Justin Erenkrantz <justin@erenkrantz.com>,
	dev@httpd.apache.org
References: <f21d814280f58782611177ce69fa79a8@ricilake.net>
 <425FE436.6060709@remulak.net> <20050415170939.GD29417@scotch.ics.uci.edu>
 <20050415172932.GE29417@scotch.ics.uci.edu> <42601A1D.6000500@remulak.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <42601A1D.6000500@remulak.net>
User-Agent: Mutt/1.5.8i

On Fri, Apr 15, 2005 at 03:46:37PM -0400, Greg Ames wrote:
> it is sounding better all the time as far as performance.  if I understand 
> you correctly I think this one eliminates the extra trips down the input 
> and output filter chains.  but unfortunately we still have the extra read() 
> compared to 1.3, and what about data stashed in the input filter chain?

Well, I think the extra read() is required if we want to see if there is a
pending request in the pipeline (heh).  I wouldn't see a way to know that
without that read() - note that if we've already read the data from the socket
(in our previous core input filter reads), we won't have to go to the network
as the brigade contains the previously read() data in a heap bucket ('stashed
away').  But, in the common case where there isn't a request in the pipeline,
then it would call read() - albeit nonblocking.  I'm guessing 1.3 just didn't
even bother doing a read() on the socket...which sort ofbegs the question, why
are we doing that in 2.x then?

But, moving it to a request output filter triggered by EOS presence does
eliminate one round trip through the filter chain which can save CPU cycles.

So, I guess what we should do is let Rici finish up the patch to implement
EATCRLF entirely via speculative reads - ensure that works and then we can
move around that code as necessary.  -- justin