httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bill Stoddard" <b...@wstoddard.com>
Subject Re: bucket siblings / thread safety
Date Tue, 01 May 2001 18:06:53 GMT

> On Tue, 1 May 2001 rbb@covalent.net wrote:
> 
> > > 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.
> 
> We already cache the apr_file_t (and I'm assuming that it works).  We
> already build a bucket out of it from the request pool.  That's not the
> problem.  It's that file_read() builds an MMAP out of the
> apr_file_t->pool, which is, I presume, why you suggest not caching the
> apr_file_t.  

That's the idea.

> But then apr_file_open becomes kind of useless, doesn't it?
> 

Huh?  I believe we can create an apr_file_t out of the request pool and stuff the fd into
it. 

> The crux of the problem is the one line in file_read() that grabs the
> apr_file_t's pool to put the MMAP in.  If we let apr_bucket_file_create()
> take a pool parameter and store that in the apr_bucket_file, then
> file_read() can create the MMAP in that pool (which presumably has at most
> the lifespan of the apr_file_t's pool).  ap_send_fd() would always pass
> the request pool to apr_bucket_file_create(), which is basically the same
> idea as you (Bill) have suggested, just slanted in a different way.
> 

I'll look into this.

Bill



Mime
View raw message