On Mon, 11 Jun 2001, Roy T. Fielding wrote:
But that's not thinking at a wide enough scope. There are lots of reasons
why I chose the analogy of bucket brigades for the original design, but one
is that we want to put the fire out. Web applications are very sensitive
to latency. The only
On Fri, 8 Jun 2001, Roy T. Fielding wrote:
Seriously, though, there is no reason for the setaside function to need
a full memory allocation system (pool) passed just to do a bit of byte
stuffing within a buffer.
It's not just a bit of byte stuffing within a buffer at all. The pool
has some
Bugger... wish I could avoid sending this to two lists, but I guess
it does overlap.
On Wed, Jun 06, 2001 at 01:04:29AM -0700, Greg Stein wrote:
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
On Wed, Jun 06, 2001 at 06:30:30PM +0200, Sander Striker wrote:
what's the profile of the memory allocation / reallocation / deallocation
like?
sander has written sma - smart memory allocator.
it basically allows you to have more control over the block
size etc for management etc
On Tue, Jun 05, 2001 at 01:49:39PM -0700, Ian Holsman wrote:
-Original Message-
From: Greg Stein [mailto:[EMAIL PROTECTED]
Sent: Monday, June 04, 2001 3:18 PM
To: new-httpd@apache.org
Subject: Re: file/mmap buckets, subrequests, pools, 2.0.18
...
Passing a pool to setaside
On Tue, Jun 05, 2001 at 05:45:15PM -0700, Greg Stein wrote:
Now, setaside(pool):
In this case, let's say that filter FOO is a (main) request filter and is
doing a setaside. It calls setaside(r-pool). The FILE bucket has its own
pool (this happens to be subreq-pool), so it calls some pool
On Tue, Jun 05, 2001 at 11:35:33PM -0400, Cliff Woolley wrote:
On Tue, 5 Jun 2001, Justin Erenkrantz wrote:
With you up until here, but how does the pool know that it won't live as
long as another pool? If a pool is a child of a pool, then we know that
it won't last as long as its parent?
On Wed, 6 Jun 2001, Greg Stein wrote:
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 said, we've seen issues with malloc() efficiency in the bucket
what's the profile of the memory allocation / reallocation / deallocation
like?
sander has written sma - smart memory allocator.
it basically allows you to have more control over the block
size etc for management etc of memory allocation / reallocation.
it's wrapped through the apr_sms
