httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From r..@covalent.net
Subject Re: [PATCH] final part of the ap_r* solution
Date Wed, 14 Feb 2001 05:01:19 GMT

> > This patch does exactly that.  It puts the power into the hands of the
> > programmer.  The "perfectly reasonable alternative" removes that power
> > from the module author, and gives it to some other module.  I thoroughly
> > dislike that.
> 
> Power to do what? Misorder output?

Power over how their code runs.  With the ap_r* patch I have posted, the
module author has complete control over how their code operates.  With the
OLD_WRITE filter, any other module that comes along can affect how the
code operates.  Personally, I would rather spend time debugging my code,
that I have complete control over, and never have to worry about it again,
than debug my code, only to find that some other module has negatively
impacted my performance, and then realize that in order to solve the
problem, I have to re-write my code to use ap_f* instead of ap_r*.

My biggest complaint against OLD_WRITE, is that it solve the exact same
problem as the brigade buffering, but it does it in a non-portable method

> > I would suggest that we run some performance numbers with both patches,
> > and at least take those into account when making this decision.
> 
> The decision isn't a performance one. Both are going to run with the same
> performance characteristics. Neither patch has been optimized for
> performance, so that doesn't help things either.

Then tune your patch.  The whole reason this thing went in was for
performance.  To say that isn't an issue now doesn't make any sense to me.

> The decision is based on whether you want to make module authors consider
> whether output misordering might occur, and make them compensate for it.
> 
> They can compensate by doing one of:
> 1) always use r->bb for brigade style output
> 2) choose one output style and stick to it
> 
> (1) is inflexible and (2) induces coupling (all subsystems must use the same
> style; they cannot be independent).

I don't see the problem with (1).  It works and it makes sense.  Sometimes
too much flexibility is actually a bad thing.  What does it buy us to
allow people to use any brigade in the handler?

> The current ap_r* scheme using the OLD_WRITE filter does not impose either
> of those two burdens on the module author. Switching to the brigade
> buffering (rather than a private buffer) would have no material impact on
> the user of the ap_r* or ap_pass_brigade (or ap_f* now!) interfaces.

That's true.  However, if I do the following:

    ap_register_output_filter("RBB_FILTER", ap_rbb_filter,
                              AP_FTYPE_CONTENT - 2);

then I remove the performance improvement added by old write whenever that
filter is used.  How am I as a module author supposed to fix that
problem?  Are you going to just say never do that?  Doesn't that remove
flexibility?  How am I supposed to even find that this is my performance
problem?

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


Mime
View raw message