>
> Uggghhhhh... I just thought of a really nasty problem with the
> mod_file_cache solution proposed earlier. I knew it was too good to be
> true. Sheesh.
>
> Thread safety gets shot to hell if we let bucket siblings span threads
> ever. All sorts of assumptions in the buckets code would get broken, eg
> that refcount increment/decrement can be done with no mutex. There's very
> little mutexing in the buckets code (ignore malloc for a minute :-)
> because of this assumption, which is a good thing. So I don't think we
> can let mod_file_cache cache a bucket. The design just doesn't account
> for it. Crap.
>
> That doesn't mean that we can't go ahead and do the lazy file->mmap
> morphing; we can and should IMO. But it does mean that that only helps
> *per-request* (or connection, possibly); it can't help us out at any
> higher-level than that.
>
> So mod_file_cache still has leakage problems. The only other solutions I
> can think of I've already posted. I'll state them again here for giggles
> (I've modified #2 to be more sane).
>
> (1) Let mmap_destroy() call apr_mmap_delete(m->mmap) after the last
> reference goes away. This still leaks sizeof(apr_mmap_t) in the cache
> pool per request that does an apr_bucket_read() and incurs extra
> syscall(s) during regular request processing. Yuck.
>
> (2) Make apr_bucket_file_create() take a pool parameter, which will be
> used to create the MMAP for the file (if any), rather than putting the
> MMAP in the same pool as the file. ap_send_fd() would pass it the request
> pool, which it would keep a reference to in the apr_bucket_file structure
> for use at whatever point in the future it might need to be MMAP'ed.
>
> I'm guessing #2 is the only feasible solution. It's not as slick and
> performant as the cached-buckets idea, but then again that one just won't
> work so too bad, I guess.
>
> But whatever the solution is, I don't really have any more mental cycles
> left that I can spend on it this week; too many other projects breathing
> down my neck. Off I go to OpenGL land...
>
Why can't we just cache the open file descriptor (not apr_file_t, but the actual
descriptor) then
build a bucket out of the request pool (just as if we opend the file as part of the
request
processing)?
Bill
