httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Stein <>
Subject Re: ap_r* performance patch
Date Tue, 23 Jan 2001 23:39:58 GMT
[ some design-style wrap-up (mostly) unrelated to the patches ]

On Mon, Jan 22, 2001 at 08:08:56PM -0800, wrote:
> The problem here is one of priorities.  I find it to be much more
> important that the solution works for modules other than the core.  Mine
> does, your's can't.

If you want to find that solution for modules, and make it available, then
great. Hopefully, it can be used for ap_r*, too. I don't believe that
apr_brigade_write is a panacea for this -- it needs more work.

I will *gladly* rip out OLD_WRITE when a lower-level solution arises which
can also solve ap_r* cleanly.

> The ordering isn't a problem with a bit of diligence.

Requiring diligence == adding bugs. Not requiring diligence means your bugs
come from elsewhere.

> The large-write
> issue is either solved, or the solution is obvious from my last patch.

Sorry, but I disagree.

> Except, buckets are defined as being read-only, so what you are saying is
> buckets are read-only, oh except for this special one that is
> read/write.  That is a poor API design, and it is inviting problems for
> module writers.

Give me a break. You're trying to latch onto semantics to support your
position. There is nothing that says we cannot have a bucket that changes
its data over time. And if/when we do, that does not impact the overall
design or the other bucket types.

> > All that aside: if you aren't intending to insert an apr_brigade_flush()
> > call into various brigade macros, then just *how* are you hoping to solve
> > the issue?
> > 
> > a) inserting calls inside the macros doesn't feel right
> > b) pushing the flush back onto the module author leads to problems
> b is not a problem.  It is a standard way of doing things.  I have never
> seen a buffering API that tries to figure out how to switch from buffered
> to non-buffered without help from the programmer.  Why are we trying to?

We aren't trying to solve buffered vs non-buffered. We're trying to solve
the ap_r* problem. Your patch introduces the b-vs-nb discrepancy and imposes
add'l requirements on module authors to keep things working.

But the point is moot for now. At some point, when we add some
bucket/brigade APIs to deal with small writes to a brigade, we can discuss
the implementation strategy then.


Greg Stein,

View raw message