[EMAIL PROTECTED] wrote:
jwoolley02/04/18 23:07:50
Modified:buckets apr_buckets_mmap.c
Log:
Fix the mmap cleanup problem seen on daedalus.
:-) :-)
I missed most of the discussion on this due to e-mail problems. Dang, I'm sure
glad I didn't have to debug this one.
Greg
PS: I still question the copying of the mmap data into the pool in
pool_setaside()... it seems to me that it's easy for that to accidentally
copy a very large file in its entirety into memory. What am I missing?
Your right, this can do that. However, we really can't keep that from
On Tue, 26 Jun 2001, Cliff Woolley wrote:
Your right, this can do that. However, we really can't keep that from
happening. In reality, the mmap_setaside function should just map it back
to a file opened out of the new pool.
I see now that by map it back to a file you meant reopen the
Instead of creating a new mmap, how about using the same one
and adding a reference count?
--Brian
Cliff Woolley wrote:
On Tue, 26 Jun 2001, Cliff Woolley wrote:
Your right, this can do that. However, we really can't keep that from
happening. In reality, the mmap_setaside function should just
At 12:05 PM 06/26/2001, Cliff Woolley wrote:
Obviously I was missing the same thing as I was missing on the
file_cleanup() thing, which is the simple fact that the original MMAP
might get deleted by the pool cleanup on the old pool. I don't know
where
my brain is today.
Anyway, the problem is
At 12:53 PM 06/26/2001, Greg Marr wrote:
At 12:05 PM 06/26/2001, Cliff Woolley wrote:
Anyway, the problem is not 100% solved. We need to make ourselves
a new
MMAP to the file that we know won't get deleted.
Why not simply reference count the MMAP/file handle?
I came up with these questions after
I came up with these questions after sending this suggestion:
Where would the reference count go?
- Instead of having an MMAP/file handle, the apr_*_t would have to
point to a structure containing the MMAP/file handle, and a reference
count. This memory for this structure could not
On 28 Feb 2001 [EMAIL PROTECTED] wrote:
pass the right value to free() to prevent segfaults and corrupted
heaps and other nasties
Ugghghhh... damn me. I'm just causing all sorts of problems, aren't I?
sigh
--Cliff