httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From r..@covalent.net
Subject Re: ap_r* performance patch
Date Tue, 23 Jan 2001 03:38:10 GMT

> > If I missed anybody, please stand up.  I would really like to call this a
> > vote at 8:00 PM PCT.  That is about 3hr 20m from now.  We have been
> > holding this vote since last thursday or friday, so it is time we made a
> > decision already.  If anybody thinkgs I should wait longer, I am perfectly
> > willing to wait until tomorrow morning at 7:00am, or suggest a different
> > time.
> 
> Your patch needs to solve these things first:

You can't dictate problems after a vote and decision has been made.

> 1) ordering
> 
> 2) large writes in ap_rputs, ap_rvputs, ap_rwrite, and ap_vrprintf
>    specifically: how will you avoid copying the content into the brigade?
> 
> 
> You've said (1) is possible (and you provided the "how") but don't want to
> do it that way. I agree that calling apr_brigade_flush() inside the brigade
> macros is bogus. I've also described the tail-bucket approach that will
> completely eliminate the apr_brigade_flush() problem. If you switch to that,
> it will completely remove the necessity for brigade_flush.

I completely disagree that we should create a bucket that can be written
to.  We currently do not have any buckets that we can write to.  I
thoroughly dislike adding a new bucket API that only works in certain
situations.

> I suspect that when you go to solve (2), the ap_r* functions are going to
> get quite a bit hairier, and the solution to those will be Apache specific
> -- exactly what you are lobbying your patch avoids.

Please actually look at the code.  This has already been solved.

> Your solutions for the above two problems are needed before applying your
> patch. I don't understand how you intend to solve them; my own thoughts on
> how to do it within your framework lead me to believe that your patch won't
> be as confined to APR as you believe.
> 
> Application of either patch should be held until the solution is evident.

Ryan
_______________________________________________________________________________
Ryan Bloom                        	rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------



Mime
View raw message