On Mon, 18 Jun 2001 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] Charlottesville, VA
