On Thu, 18 Apr 2002, Sander Striker wrote: > Maybe asking the obvious here, but can't we solve this with a > simple reference counter? IOW last one destroys the mmap.
We already have one. That's not the problem. The problem is this sequence of events: 1) create a brigade 2) create an mmap in the same pool as the brigade (or a subpool) 3) place the mmap in an mmap bucket 4) insert the mmap bucket into the brigade 5) clean up the brigade's pool at step 5, we'll crash, because the cleanup on the apr_mmap_t destroys it before the brigade cleanup runs (since cleanups are in LIFO order) and the brigade cleanup deletes the mmap bucket which wants to call apr_mmap_delete on an apr_mmap_t that was already destroyed. So one solution would be to remove the apr_mmap_delete call from mmap_bucket_destroy() completely. However, the whole reason it's in there in the first place is that it's useful for the FILE buckets code, wherein file_bucket_read() could conceivably create many gigabytes worth of mmap'ed regions in the same pool before that pool gets cleaned up, in hunks of about 12MB per region, even though the mmap bucket referring to each region was deleted as that region was processed. So it makes sense for mmap_bucket_destroy() to call apr_mmap_delete() when the last bucket referring to that region goes away. These facts are obviously in conflict. The only way around it is to ensure that the buckets code knows when it's allowed to call apr_mmap_delete() and when it's not. The only way to do that is to have some cleanup that we can guarantee will run *before* the apr_mmap_t goes away on us [or at least before mmap_bucket_destroy is called on that apr_mmap_t, though the former is easier to do]. Make sense? --Cliff -------------------------------------------------------------- Cliff Woolley [EMAIL PROTECTED] Charlottesville, VA
