This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: A sick idea - mmapped file output


Michael Meissner <meissner@cygnus.com> writes:

> Just as a data point -- I have used systems in the past where writes via
> mmap did not always get read properly via read, due to mmap not updating
> the buffer cache.

This is the case on HP-UX 10.20 and at least one of the betas of MacOS X,
according to reports we've received for INN (which makes extensive use of
mmap).  After those reports, we started testing in configure to see if
this was the case and working around it, so there may well be additional
systems in this category that are now being handled correctly and hence
haven't complainted to us.

The configure test available by request if anyone wants to see it.  (It's
pretty straightforward, and gcc developers may not want to see it as it's
not under the GPL and the copyright history is unclear for inclusion in an
FSF-owned project.)

> Also whether you get different semantics if $TMPDIR points to a NFS file
> system.

Non-trivial use of mmap over NFS is, from what I've heard, a recipe for
deep hurting.

> Finally, writev may win providing the OS implements writev in a smart
> fashion (rather than having libc iterate with multiple writes, which
> some system have used in the past).

Be careful of using write or writev without wrappering them to handle
partial writes.  I've seen systems that have returned partial writes on
write or writev even to disk files (!!).

-- 
Russ Allbery (rra@stanford.edu)             <http://www.eyrie.org/~eagle/>

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]