Return-Path: Delivered-To: apmail-new-httpd-archive@apache.org Received: (qmail 69604 invoked by uid 500); 23 Jan 2001 23:39:38 -0000 Mailing-List: contact new-httpd-help@apache.org; run by ezmlm Precedence: bulk Reply-To: new-httpd@apache.org list-help: list-unsubscribe: list-post: Delivered-To: mailing list new-httpd@apache.org Received: (qmail 69135 invoked from network); 23 Jan 2001 23:39:25 -0000 X-Authentication-Warning: kurgan.lyra.org: gstein set sender to gstein@lyra.org using -f Date: Tue, 23 Jan 2001 15:39:58 -0800 From: Greg Stein To: new-httpd@apache.org Subject: Re: ap_r* performance patch Message-ID: <20010123153958.F704@lyra.org> Mail-Followup-To: new-httpd@apache.org References: <20010122195317.Z704@lyra.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: ; from rbb@covalent.net on Mon, Jan 22, 2001 at 08:08:56PM -0800 X-URL: http://www.lyra.org/greg/ X-Spam-Rating: h31.sny.collab.net 1.6.2 0/1000/N [ some design-style wrap-up (mostly) unrelated to the patches ] On Mon, Jan 22, 2001 at 08:08:56PM -0800, rbb@covalent.net 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. Cheers, -g -- Greg Stein, http://www.lyra.org/