Greg Stein <[EMAIL PROTECTED]> writes:
> On Tue, May 01, 2001 at 03:41:50PM -0500, William A. Rowe, Jr. wrote:
> > From: "Bill Stoddard" <[EMAIL PROTECTED]>
> > Sent: Tuesday, May 01, 2001 11:56 AM
> >
> > > 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)?
> >
> > What file descriptor? This is the wrong way to go, IMHO. We invented
> > apr_file_t's for a reason. Provide a way to 'realloc/copy' an apr_t
> > entity into another pool (different lifetime) portably, don't go assuming
> > stuff. On win32, we MUST know if the file handle was opened normally,
> > or for overlapped IO (no current file position) access.
>
> We already have it. It's called apr_file_dup().
>
> Keep the apr_file_t open and in the cache. When you want to deliver it, do
> the following:
>
> status = apr_file_dup(&new_file, cached_file, r->pool);
> bucket = apr_bucket_file_create(new_file);
Bill and I thought of this yesterday at almost the same instant. The
question remaining is the cost of DuplicateHandle() or dup().
Certainly it is better than opening the file from scratch but one
still wonders since the application here is for a cache...
(and how about those cool discrepancies between apr_file_dup() on
Win32 and apr_file_dup() on unix? consider just the buffering to
start)
--
Jeff Trawick | [EMAIL PROTECTED] | PGP public key at web site:
http://www.geocities.com/SiliconValley/Park/9289/
Born in Roswell... married an alien...
