Looking closer, this is not necessarily the case here.
Git uses MAP_PRIVATE, because that whole pack-file mapping was really
*meant* to map an existing read-only pack-file, and fast-import seems to
really be screwing with it.
It so happens that Linux has a particularly clean and streamlined VM, and
if you do only reads to a MAP_PRIVATE mapping on a normal filesystem,
you'll always be as coherent as with MAP_SHARED because Linux will simply
map in the page cache pages directly.
But this is definitely not portable, and the git fast-import mmap window
usage before Shawn's patch it was simply wrong.
So in this case, it really was git that was crap.
It just happened to work because the Linux mmap handling is just generally
pretty sane. It probably also worked fine on pretty much any other modern
UNIX (ie Solaris).
I'm not quite sure what OS X does to MAP_PRIVATE mappings, but if OS X is
still based on Mach (with FreeBSD just as a single-server on top), I
suspect that may be why it broke on OS X. The Mach VM is insanely complex
and does really odd things.
But the fact is, without MAP_SHARED, you shouldn't expect things to be
coherent, even if they often will be (especially for PROT_READ).
Btw, even with Shawn's patch, I wonder if the index_data usage is correct.
Linus
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
