On Thu, 26 Apr 2001, Greg Stein wrote:
> If the data is in a pool, then a pool bucket should be used (not an immortal
> bucket). Sure, the data has (effectively) an immortal lifetime as far as the
> request goes, but that path leads to nightmare.
>
> Immortal buckets should only be for static/const data. Use pool buckets for
> pool data.
Exactly. That's why I changed my mind.
When I originally suggested the use of an immortal bucket, it was when I
thought that the data in the bucket was one of either a static string (the
default) or a string allocated from the cmd->pool at server config time.
In either case, the data was invariant during the course of normal request
processing, meaning that the buckets code could just treat it as immortal.
But then I realized that the error message was configurable within the
document itself, meaning that the error message used is actually allocated
from the connection pool, at which point it would have to be a pool
bucket. But it doesn't save us much to make it a pool bucket (one malloc
and one memcpy, to be precise), and it adds the registration of a pool
cleanup. It would only be a real gain if the include_ctx_t also contained
a pointer to the error message's bucket, and for each error it encountered
it did an apr_bucket_copy(), which incurs a single malloc. But since it's
the error case anyway, I punted and said leave it the way it is (which is
to copy it to the heap right away).
At any rate, it must be either heap or pool. The difference is basically
just a matter of timing.
--Cliff
--------------------------------------------------------------
Cliff Woolley
[EMAIL PROTECTED]
Charlottesville, VA
