Re: cvs commit: apr-util/buckets apr_buckets_mmap.c

2002-04-19 Thread Greg Ames
[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

Re: cvs commit: apr-util/buckets apr_buckets_mmap.c

2001-06-26 Thread rbb
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

Re: cvs commit: apr-util/buckets apr_buckets_mmap.c

2001-06-26 Thread Cliff Woolley
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

Re: cvs commit: apr-util/buckets apr_buckets_mmap.c

2001-06-26 Thread Brian Pane
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

Re: cvs commit: apr-util/buckets apr_buckets_mmap.c

2001-06-26 Thread Greg Marr
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

Re: cvs commit: apr-util/buckets apr_buckets_mmap.c

2001-06-26 Thread Greg Marr
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

Re: cvs commit: apr-util/buckets apr_buckets_mmap.c

2001-06-26 Thread rbb
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

Re: cvs commit: apr-util/buckets apr_buckets_mmap.c

2001-02-28 Thread Cliff Woolley
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