> 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.
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
