Mailing-List: contact new-httpd-help@apache.org; run by ezmlm
Precedence: bulk
Reply-To: new-httpd@apache.org
Message-Id: <5.0.2.1.2.20010122125902.00aa75c0@pop.charter.net>
Date: Mon, 22 Jan 2001 13:16:23 -0500
To: new-httpd@apache.org
From: Greg Marr <gregm@alum.wpi.edu>
Subject: Re: the ap_r* thing (was: Re: Apache 2.0 beta STATUS)
In-Reply-To: <20010122033645.G704@lyra.org>
References: <000101c08438$216e84e0$92c0b0d0@roweclan.net>
 <20010121212627.V704@lyra.org>
 <000101c08438$216e84e0$92c0b0d0@roweclan.net>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

At 06:36 AM 01/22/2001, Greg Stein wrote:
>*) assume it used ap_r*. There will be content sitting in r->bb. I 
>construct
>    my brigade for other pieces of the MERGE response and call
>    ap_pass_brigade(). I've now misordered the response because my 
> brigade
>    went before the stuff sitting in r->bb.
>
>*) let's say that I send some data with ap_r* and then call the DAV 
>utility
>    function. assume it uses ap_pass_brigade(). It constructs the 
> brigade and
>    passes it. Again: a misorder occurs because the brigade from the 
> utility
>    went out before the r->bb brigade.
>
>An answer is to tell everybody "you must use r->bb, and never your 
>own brigade."

A better answer is to tell people to ap_rflush() before calling 
functions they don't control that may generate output, and to call 
ap_rflush after generating output using ap_r* if the function may be 
called by functions they don't control.

>By using a filter in my patch, I've trapped all output to the 
>network.  Nothing can go without passing through that 
>filter.  Therefore, I have a perfect choke point to ensure that I 
>can order all the output properly.

Actually, all the output better be ordered properly before it gets to 
your filter, since your filter can be pushed down the stack by 
another filter inserting itself higher up.

Is there ever the possibility of a filter being inserted into the 
stack after the first ap_r* call?  If so, and that filter gets placed 
before your filter, won't that totally hose any data currently in the 
output filter's buffer?

>My patch has *zero* requirements on module authors.  Use whatever 
>API you have been using or want to use.  It doesn't matter, and you 
>don't ever have to worry about what somebody else is using.  There 
>is no possibility for synchronization problems.

That's true, but it also has the possibility that the entire thing 
can be turned off by a filter being inserted above it in the stack, 
in which case Apache's back at its current performance.

>I'm all for creating an APR solution, but the number one priority is 
>Apache.  If our solution also happens to work for APR, then 
>great.  But I don't believe that we can necessarily say "this works 
>for APR" and then wedge it into Apache and make module authors need 
>to be aware of the various output mechanisms and compensate for 
>potential ordering problems.

It removes any possibility of output ordering problems, but also adds 
a possibility of a filter ordering problem rendering it ineffective.

>*) ap_rwrite(my_buffer, 100000, r)

That one's pretty nasty.

>*) ap_rprintf(r, "<D:compare-report>%s</D:compare-report>", report)
>    report == 200k string

As is this one.

-- 
Greg Marr
gregm@alum.wpi.edu
"We thought you were dead."
"I was, but I'm better now." - Sheridan, "The Summoning"