httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Stein <>
Subject transient buckets (was: Re: cvs commit: httpd-2.0 STATUS)
Date Thu, 18 Jan 2001 00:35:29 GMT
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


Greg Stein,

View raw message