Mercurial > hg
changeset 52117:db1980a361cb
rev-branch-cache: disable mmapping by default on Windows
See the inline comment for why. The commands work, other than leaving extra
files laying around.
Perhaps there's some way to get this to work like on posix with some
`CreateFile` magic (though it already uses `FILE_SHARE_DELETE`, so I'm not sure
offhand what else we can do). However big picture- it seems wrong that the old
file is left mmapped, a new one moved into place, and the mapping left over the
old file instead of retargeted to the new file. That's got to be a bug on posix
too, in a long running process like chg, right? If the memory is read again for
some reason, it will be stale data.
author | Matt Harbison <matt_harbison@yahoo.com> |
---|---|
date | Fri, 18 Oct 2024 13:21:23 -0400 |
parents | c424df1248a3 |
children | 1bebe07bfd40 |
files | mercurial/branching/rev_cache.py mercurial/configitems.toml |
diffstat | 2 files changed, 15 insertions(+), 2 deletions(-) [+] |
line wrap: on
line diff
--- a/mercurial/branching/rev_cache.py Fri Oct 18 13:45:13 2024 -0400 +++ b/mercurial/branching/rev_cache.py Fri Oct 18 13:21:23 2024 -0400 @@ -14,6 +14,7 @@ from .. import ( encoding, error, + pycompat, util, ) @@ -176,7 +177,19 @@ if self._names: try: - usemmap = repo.ui.configbool(b'storage', b'revbranchcache.mmap') + # In order to rename the atomictempfile in _writerevs(), the + # existing file needs to be removed. The Windows code + # (successfully) renames it to a temp file first, before moving + # the temp file into its place. But the removal of the original + # file then fails, because it's still mapped. The mmap object + # needs to be closed in order to remove the file, but in order + # to do that, the memoryview returned by util.buffer needs to be + # released. + usemmap = repo.ui.configbool( + b'storage', + b'revbranchcache.mmap', + default=not pycompat.iswindows, + ) if not v1_fallback: with repo.cachevfs(_rbcrevs) as fp: if usemmap and repo.cachevfs.is_mmap_safe(_rbcrevs):