On Fri, Aug 10, 2012 at 7:13 AM, Junio C Hamano <gits...@pobox.com> wrote:
> By the way, you can only detect such inconsistency when you are
> lucky enough that you catch the other person in the middle of
> writing.
> If the index you are looking at holds a large tree with very many
> paths, it is possible that there are two large directories, and
> after you read all entries from one, the other process starts
> modifying the paths in that directory, without you ever finding it
> out.  If the goal of the topic is to make the index work better in
> projects with large trees, it may be wise to think about locking the
> whole thing, so that you do not have to rely on the per-entry crc
> and you being lucky to detect such a race.  The per-entry crc, as
> far as I understand, may have been introduced primarily to detect
> on-disk data corruption; it is not a suitable mechanism to detect
> conflicting accesses.

So we acquire the lock just before we need to write, or at the time we
open for reading?
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to