httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From <...@covalent.net>
Subject Re: bucket siblings / thread safety
Date Tue, 01 May 2001 16:53: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)
then
> build a bucket out of the request pool (just as if we opend the file as part of the request
> processing)?

Why not cache the apr_file_t?  It should be cache-able, and it would make
things more portable, wouldn't it?  The only problem is that we might
modify an apr_file_t during request processing, but we shouldn't be, so we
should be okay.

Ryan

_______________________________________________________________________________
Ryan Bloom                        	rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------


Mime
View raw message