On Fri, Jun 01, 2001 at 11:00:08AM -0700, [EMAIL PROTECTED] wrote:
>...
> This is realitively simple. A while ago, I changed the default handler to
> use the connection pool to fix this problem. A couple of months ago, Dean
> pointed out that this was a major resource leak. After 2.0.16, somebody
> (Roy?) pointed out that this was a pretty big problem when serving a lot
> of very large files on the same connection.
>
> The solution was a simple loop at the end of the core_output_filter that
> reads in the data from the file to memory. This is okay to do, because we
> are garuanteed to have less than 9k of data. It sounds like the problem
> is that we don't read in the data if we have an MMAP, or we may not be
> getting into the loop on sub-requests.
What about the idea to have setaside() take a pool parameter? The bucket
should ensure that its contents live at least as long as the pool.
For an MMAP bucket, if the given pool is the same or a subpool of the mmap's
pool, then nothing needs to happen. If the pool is a parent of the mmap's
pool, then the bucket needs to read its contents into a new POOL bucket
attached to the passed-in pool.
Other buckets operate similarly. This would ensure that we can safely set
aside any type of bucket, for any particular lifetime (whether that is for a
connection or a request or whatever).
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
