"Zack Weinberg" <zack@xxxxxxxxxxxx> writes: > For Autoconf's purposes, what we really need to know is: on OpenBSD, > what does an application need to do after it modifies a MAP_SHARED > mapping using memory writes to make those writes visible to read()? 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 other problem we encountered at the time was with NFS. Even on platforms where normally changes to a MAP_SHARED mapping were immediately visible to read() and changes with write() were immediately visible to the mapping, this often would break if the underlying file system were a remote NFS mount. In that case, an explicit msync() helped with writes. Reads were, as I recall, a more complicated problem since it wasn't obvious when to call msync(). INN has code to call fstat() on the file descriptor underlying the MAP_SHARED mapping because the symptom we saw at the time is that this would return ESTALE if there had been a write (which INN then uses as a trigger to unmap and remap the file). Here too I have not revalidated this subsequently. This would have been in the days of NFSv3 (if not NFSv2 in places). -- Russ Allbery (eagle@xxxxxxxxx) <https://www.eyrie.org/~eagle/>
