On Tue, Jun 19, 2001 at 08:15:58AM -0700, [EMAIL PROTECTED] wrote: > > > > (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? > > Sooner or later, we are going to be writing the file someplace. That > could be the network, or it could be into memory to do some mucking with > the data. Since we are either dup'ing it or mmap'ing it, I figured we > could be conservative here and mmap the data. If we dup it here, and then > have to read, then we have dup'ed and mmap'ed. This way, we only mmap the > data.
The setaside() could be called on *really* large files. Calling mmap could be a very bad thing. Just dup the FILE bucket and leave it at that. The decision to do the mmap can/should come when it becomes necessary. >... > > Isn't it just a matter of killing the cleanup associated with one pool > > and registering the cleanup with the new pool? We shouldn't go an unregister the original apr_file_t -- that just destroys the thing. But this is independent of the cleanup. Calling apr_file_close() on one of the files should not close the other apr_file_t. That would be Badness. I'm with Ryan: dup the bugger. Cheers, -g -- Greg Stein, http://www.lyra.org/
