httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bill Stoddard" <>
Subject Re: bucket siblings / thread safety
Date Tue, 01 May 2001 16:56:44 GMT
> 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)
build a bucket out of the request pool (just as if we opend the file as part of the request


View raw message