apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Stein <gst...@lyra.org>
Subject Re: file_setaside()
Date Tue, 26 Jun 2001 09:15:41 GMT
On Tue, Jun 19, 2001 at 08:15:58AM -0700, rbb@covalent.net wrote:
> > > > (2) Why should file_setaside mmap the file?  I'd think that we'd want
> > > > 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.


Greg Stein, http://www.lyra.org/

View raw message