[Stupid] question about OS locks

[John Arbash Meinel]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Alexander Belchenko wrote:
> New WT4 format use OS locks, that behaves differently on different platforms,
> and don't work at all on some old platforms (like win98).
> 
> I wonder why bzr can't use old locking schema with lockdirs?
> I understand that lockdirs is slower than OS locks.
> But...
> 
> But now we have working OS locks, and we have working dir locks.
> Can we provide one additional variant of WT4 format, that use lockdirs
> instead of OS locks? And make this format as default for win32?
> In this case we could have 2 variants of dirstate WT:
> the first one is very-very fast (default for all Linux users),
> and second not so fast, but more robust, (default for poor win32 users)?
> And both this formats will be supported by 0.16, per example.
> 
> I should to ask this before I try to implement draft of new filesystem-based locks,
> that again will behaves differently on Linux and Windows.
> What's actually wrong with using lockdirs for WT?
> 
> [µ]

Actually, we still use a LockDir for WT4. The reason we *also* have an
OS lock, is because there is one file that we are writing in-place
(dirstate), which we don't want a writer to write in-place while we may
be reading from another process.

In the past, read-locks were no-ops because everything was always in a
consistent state (at least from a POSIX point of view). On Posix,
(linux, bsd, Mac, etc) if you have a file open, and someone renames
another file into that place, your current file doesn't change. So your
read will complete without corruption.

On Win32, that rename fails, so technically you still have isolation.
(But now the writer needs to be able to handle failing.)

(that is currently only for .bzr/branch/revision-history, we used to
also rename into place for .weave files).

Our other files are all append-only (.knit, .kndx, etc). So when a
writer updates them, it doesn't invalidate anything that has already
been read.


With dirstate we tried to do a 'modify-in-place' for a variety of
reasons, so we need to use an OS lock to tell the writer not to
overwrite a file which is currently being read.


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.

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.)

John
=:->
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGIlCkJdeBCYSNAAMRAuf0AJ9R2QW0lVtqCRvfK3khjBtpyfGymwCaA2QH
9i1e97Ot7R+lapfwdRtTdTI=
=IiMR
-----END PGP SIGNATURE-----