[Stupid] question about OS locks

[Martin Pool]

On 4/16/07, John Arbash Meinel <john at arbash-meinel.com> wrote:
> So really, the only way to get rid of OS locks is to have a format which
> doesn't write in the same place that readers read. We might be able to
> get away with changing dirstate to write to a temporary file, and then
> overwrite the existing one (either with a rename out of the way and
> rename into place, or just a rename overwrite on Posix).
>
> We thought we could get away with OS locks, and other than Win98, I
> think we can. There are a few other difficulties we are running into
> ('bzr diff' doesn't work if 'bzr commit' is running in another window,
> and vice-versa). So we could decide to avoid OS locks again.

I would like to avoid them; from the other thread about this it seemed
like it would be possible but I may be missing something.

> Part of the desire, though. Is that we would like to do partial updates
> to dirstate. When you have 10,000 entries, and the mtime changes for 1
> file, you would rather not have to write out all 10,000 files. (As long
> mtime and sha1 fit in the same size, you could just update those bytes.)

I think the most important case for rewriting in place is when
updating the integrated hashcache, which is what John refers to here.
(Adding or removing files is going to tend to require inserting or
removing records, and while you could just rewrite the file from that
point onwards it is maybe not such a compelling case, and you will
rewrite half of it on average anyhow.)

When updating the hashcache it does seem possible that we can do it in
place and without needing read locks.  All we update is the stat
fingerprint and the file hash.  I assert that this is possible because
the worst that can happen is that the reader sees one record which has
been partially updated.  The worst that can happen is that the reader
will see an incorrect value, and decide to re-read the file.

(In passing perhaps all we really need to store for text files is not
the sha1 of the content but just a bit saying "modified from parent or
not"?)

If we did this then presumably processes doing logical read operations
would need to still take the lockdir to update the hashcache fields.

-- 
Martin