httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Stein <gst...@lyra.org>
Subject Re: file/mmap buckets, subrequests, pools, 2.0.18
Date Fri, 01 Jun 2001 20:35:32 GMT
On Fri, Jun 01, 2001 at 11:00:08AM -0700, rbb@covalent.net 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/

Mime
View raw message