apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Cliff Woolley <cliffwool...@yahoo.com>
Subject Re: file_setaside()
Date Mon, 18 Jun 2001 21:43:54 GMT
On Mon, 18 Jun 2001 rbb@covalent.net wrote:

> > (1) Shouldn't the pool passed into file_make_mmap() and apr_file_dup() be
> > "pool" and not "p"?  (It'd be easier to see that this is a problem if they
> > were called "reqpool" and "curpool" instead of "pool" and "p"
> > respectively, or something like that.)
>
> I think this is a bug, but I need to look closer......  Yep, bug.

Okay.  I'll commit a fix for it.

> > (2) Why should file_setaside mmap the file?  I'd think that we'd want to
> > keep it as a file as long as possible to make it easier to use
> > sendfile()... what am I missing?
>
> We are going to be copying something.  I figured mmap'ing the file would
> be a bit better, because we could write the file out.  Either way, it
> doesn't really matter.

<shrug>

> > (3) You don't really need to dup() the file, do you?  You can palloc a new
> > apr_file_t in the requested pool and use apr_os_file_get() and
> > apr_os_file_put() to move the os file handle into it.  mod_file_cache in
> > Apache does something like this.  It should be cheaper to do this than to
> > do a full dup(), I think.
>
> The file was opened with the request->pool.  If we just
> apr_os_file_get/put, we will still close the file when the request_pool is
> cleared.  We have to dup, or the file won't be available to us, and the
> original bug will be back.

Ahh, yes, I see the difference -- mod_file_cache knows a priori that the
pool the its cached file was opened into will live longer than the r->pool
it copies into, whereas this is just the opposite.  Gotcha.  dup() it is.

--Cliff

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



Mime
View raw message