Re: git status always modifies index?

From: Junio C Hamano <gitster@pobox.com>
Date: Nov 27, 2017, 00:47 UTC
Message-ID: <xmqq7euch7jb.fsf@gitster.mtv.corp.google.com>
In-Reply-To: <20171126192749.GC1501@sigill>

Jeff King <peff@peff.net> writes:

> I'm not sure I agree. Lockless writes are actually fine for the original
> use case of --no-optional-locks (which is a process for the same user
> that just happens to run in the background).

The phrase "lockless write" scares me---it sounds as if you overwrite the index file no matter what other people (including another instance of yourself) are doing to it.

    Side note: What 'use-optional-locks' actually does is not to
    give any file descriptor to write into when we invoke the
    wt-status helpers (which would want to make an opportunistic
    update to the index under the lock), so "--no-optional-locks" is
    quite different from "lockless write".  Whew.  It is part of
    what "semantically read-only things do not write" would have
    been.

How would a true "lockless write" that is OK for background opportunistic refresh work? Read, compute and then open the final index file under its final name for writing and write it out, without involving any rename? As long as it finishes writing the result in full and closes, its competing with a real "lockful write" would probably be safe when it loses (the lockful one will rename its result over to the refreshed one). It cannot "win" the race by writing into the temporary lock file the other party is using ;-) But it may lose the race in a messy way---the lockful one tries to rename its result over to the real index, which the lockless one has still open and writing. Unix variants are probably OK with it and the lockless one would lose gracefully, but on other platforms the lockful one would fail to rename, I suspect? Or the lockless one can crash while it is writing even if there is no race.

Or do you mean something different by "lockless write"?