httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Cliff Woolley <cliffwool...@yahoo.com>
Subject Re: bucket siblings / thread safety
Date Tue, 01 May 2001 17:50:19 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.  But then apr_file_open becomes kind of useless, doesn't 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.

Back to the polygons...

--Cliff

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



Mime
View raw message