httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Cliff Woolley <cliffwool...@yahoo.com>
Subject bucket siblings / thread safety
Date Tue, 01 May 2001 04:30:53 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...

--Cliff


--------------------------------------------------------------
   Cliff Woolley
   cliffwoolley@yahoo.com
   Charlottesville, VA



Mime
View raw message