<[EMAIL PROTECTED]> writes:
> > (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.
Why would we need to write the file out?
> Either way, it
> doesn't really matter.
I thought it mattered because we prefer having a file descriptor in
core_output to having an mmap in core_output. I guess I'm missing
your point.
> > (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.
Isn't it just a matter of killing the cleanup associated with one pool
and registering the cleanup with the new pool?
--
Jeff Trawick | [EMAIL PROTECTED] | PGP public key at web site:
http://www.geocities.com/SiliconValley/Park/9289/
Born in Roswell... married an alien...
