On Tue, 1 May 2001 [EMAIL PROTECTED] 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
[EMAIL PROTECTED]
Charlottesville, VA
