Howard Chu via Discussion list for the autoconf build system <autoconf@xxxxxxx> writes: > Russ Allbery wrote: >> Many years ago when I did work on this for INN to make heavier use of >> mmap for its new (at the time) overview system, calling msync() after >> changes to a MAP_SHARED mapping would cause the writes to be visible to >> read() on some platforms, and likewise to make write() modifications >> visible in the shared map. This was more than 20 years ago, though, >> and while INN still has all of that portability code, we haven't >> systematically tested it in quite a while. > The documentation for msync only says that it will flush out changes > made to a writable mmap region out to the filesystem. I guess that means > that they should then be visible to filesystem-oriented APIs like read() > but that isn't explicitly stated. > Also, since it only talks about changes made to mappings, it doesn't > imply anything at all about changes made via write() or whether they > become visible in a mapping. > I think the fact that this worked for INN was probably mostly luck. This is entirely possible, although I will say that the people for whom the code broke with simple mmap did report that it fixed their problems. It's probably also worth noting that once you start calling msync, any performance advantages of mmap are likely gone and the code may now be slower than if you just used pread and pwrite. INN added this code because we didn't want to code a pread/pwrite fallback for code maintenance reasons, not for performance reasons. -- Russ Allbery (eagle@xxxxxxxxx) <https://www.eyrie.org/~eagle/>
