Return-Path: Delivered-To: apmail-new-httpd-archive@apache.org Received: (qmail 63899 invoked by uid 500); 18 Jan 2001 00:34:34 -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 63849 invoked from network); 18 Jan 2001 00:34:33 -0000 X-Authentication-Warning: kurgan.lyra.org: gstein set sender to gstein@lyra.org using -f Date: Wed, 17 Jan 2001 16:35:29 -0800 From: Greg Stein To: new-httpd@apache.org Subject: transient buckets (was: Re: cvs commit: httpd-2.0 STATUS) Message-ID: <20010117163528.J7731@lyra.org> Mail-Followup-To: new-httpd@apache.org References: <20010112121527.I4640@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 dgaudet-list-new-httpd@arctic.org on Mon, Jan 15, 2001 at 09:20:01AM -0800 X-URL: http://www.lyra.org/greg/ X-Spam-Rating: h31.sny.collab.net 1.6.2 0/1000/N On Mon, Jan 15, 2001 at 09:20:01AM -0800, dean gaudet wrote: > On Fri, 12 Jan 2001, Greg Stein wrote: > > Consider: our main problem is the allocation of the brigade and the > > transient bucket. We use the transient bucket to defer copying until > > necessary. That is an important part, so we shouldn't lose that. > > the transient bucket cann't defer copying on ap_rputs, it has to copy > immediately (because there's no reference counts for C strings). this is > the broken part, this should be lost. The transient bucket was defined specifically to deal with this situation. If a bucket is to be held past the return-from-call point of a function, then the code must call the "setaside" function in the bucket. The setaside will ensure that the bucket can live past the return. In the case of a transient bucket, it copies the value to the heap. Transient buckets were created so that we can defer the copying as long as possible. If the bucket hits the network stack, then it could even go out over the network without a copy(!). >... > > Consider: ap_r* are NOT re-entrant. Across all the functions. > > i don't understand the significance of this -- you shouldn't have more > than one thread writing to the client at the same time. supporting > re-entrancy is overkill. Agreed. That is what I was saying. Basically: I wanted to clarify that that fact existed, and that we could *use* that fact to take some shortcuts. In this particular case, I believe that we can avoid the allocation of the brigade and bucket structures. Each ap_r* call would not have an allocation unless/until a setaside occurs. If the lower level did a copy (into an existing buffer) rather than a setaside, then we wouldn't have any additional allocations. >... > also the solutions i've seen so far assume that httpd is the only thing > which requires buffered i/o. it isn't... this stuff belongs in APR. We *need* a solution for Apache. It would be *nice* to have a solution for APR. Cheers, -g -- Greg Stein, http://www.lyra.org/