Re: Explanation for dropping write-back in mmap

Ramkumar Ramachandra [off-list ref] wrote:

In the commit f48000fcbe100, you've forced the caller to use
MAP_PRIVATE in the alternative mmap implementation dropping write-back
support. Could you kindly explain the rationale for this? David's SVN
exporter uses mmap with MAP_SHARED, and we figured that the merge
immediately breaks this functionality.

Noticed-by: Jonathan Nieder [off-list ref]

-----------------------------------------------------------------------------------------------------------
commit f48000fcbe1009c18f1cc46e56cde2cb632071fa
Author: Junio C Hamano [off-list ref]
Date:   Sat Oct 8 15:54:36 2005 -0700

    Yank writing-back support from gitfakemmap.

    We do not write through our use of mmap(), so make sure callers pass
    MAP_PRIVATE and remove support for writing changes back.

    Signed-off-by: Junio C Hamano [off-list ref]
-----------------------------------------------------------------------------------------------------------

It got dropped because we never really used it.  In almost every
location we were only mapping a file for reading, but were writing
through normal IO write functions.  The Windows emulation code at
that time was using malloc()+read() to emulate mmap(), and thus
any modifications made to the buffer would not be flushed back.

The one place where we were doing both was fast-import, but it was
playing loose with the mmap consistency rules.  I think we have
fixed that code since then to ensure the data stays consistent on
all platforms.

I would strongly suggest finding another way to implement the SVN
exporter, without using MAP_SHARED.

-- 
Shawn.