httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Stein <>
Subject Re: file/mmap buckets, subrequests, pools, 2.0.18
Date Wed, 06 Jun 2001 08:04:29 GMT
On Tue, Jun 05, 2001 at 11:25:43PM -0400, Cliff Woolley wrote:
> On Tue, 5 Jun 2001, Greg Stein wrote:
> > The basic problem with the current setaside() function is that it doesn't
> > say *how long* the set-aside bucket should be able to live. Thus, it must
> > implement logic to "live forever" (to be conservatively corect), or it will
> > simply fail in some circumstances. But then we have the problem that most
> > buckets *don't* implement "live forever". The FILE bucket doesn't do
> > anything at all; thus, it dies when the subrequest pool goes away.
> +1.  I like this approach.  For clarity, a setaside of a transient bucket
> would result in what?  A pool bucket?  Or should we just go ahead and
> make it a heap bucket like we're doing now?

Tough call. A POOL bucket is nominally "safer" than a HEAP bucket. But *IF*
we are careful to ensure the HEAP bucket gets placed into a brigade, then we
are guaranteed it will be tossed.

That is the crux: malloc() and free() are perfectly fine functions. Any
correctly programmed piece of software will have no leaks. But we all know
how well that works in real life :-) Simiarly, HEAP buckets are fine *IF*
you ensure they get into a brigade. And we have the same potential...

I believe the proper answer is:

    Copy the data into a HEAP bucket. And note that a HEAP bucket does not
    implement setaside() because it is immortal data (until the bucket is
    explicitly freed).

    Rationale: if we copied into a POOL, then we could possibly be required
    to copy *again* into a different pool. By using a HEAP bucket, we will
    copy from <wherever> into a memory buffer, at most, once.

This policy applies to all setaside() implementations where they want to
copy memory from <wherever> into memory for a HEAP/POOL bucket.

That said, we've seen issues with malloc() efficiency in the bucket code.
Using a POOL bucket has obvious performance implications. But on the
gripping hand, we have the up-and-coming fast-malloc patches from FirstBill,
et al. Those patches could mean that efficiency will not be the
determination between HEAP and POOL.

And one more comment: copying into a POOL bucket may be fine. I really don't
think that we will call setaside() all that often (we call it once: in
ap_save_brigade; ap_save_brigade is called from five points). Since we don't
call it often, then we may not be subject to the double-copy that I
mentioned. Or in the case of the CORE filter, that extra-copy could be (at
most) 9K of data.


Greg Stein,

View raw message