Martijn van Oosterhout <kleptog@svana.org> writes:
>> For instance, HP says
>>
>> It is also unspecified whether write references to a memory region
>> mapped with MAP_SHARED are visible to processes reading the file and
>> whether writes to a file are visible to processes that have mapped the
>> modified portion of that file, except for the effect of msync().
>>
>> So unless you want to msync after every write I do not think this can fly.
> Well ofcourse. The entire speed improvment is based on the fact that mmap()
> is giving you a window into the system disk cache. If the OS isn't built
> that way then it's not going to work. It does work on Linux and is fairly
> easy to test for.
You mean "today, using the kernel version I have and allowing for the
current phase of the moon, it appears to work". I read the following in
the mmap(2) man page supplied with RH Linux 7.2:
MAP_SHARED Share this mapping with all other processes
that map this object. Storing to the region is
equivalent to writing to the file. The file
may not actually be updated until msync(2) or
munmap(2) are called.
That last seems to make it fairly clear that the mmap region should not
be taken as exactly equivalent to the file, despite the preceding
sentence. I also note a complete lack of commitment as to whether
writes to the file reflect instantly into the mmap'd region...
regards, tom lane