[Success!] Re: [MERGE] Implement bzrlib.lock with CreateFile rather than LockFileEx on win32 (operational part)

[John Arbash Meinel]

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

Martin (gzlist) wrote:
> On 02/07/2009, John Arbash Meinel <john at arbash-meinel.com> wrote:
>> Basically, though it is because *in process* locking is not properly
>> exclusive. It is still properly exclusive *between* processes.
> 
> Aha, this is the detail I'd not grasped. So, the nix locks do protect
> against the most likely source of problems.
> 
> Thanks,
> 
> Martin
> 

Right. So internally, we allow you to take a "read lock" on top of a
"write lock", considering it a no-op. (We just don't issue the syscall.)
What is failing is that sometimes we access a file on disk via more than
one object in memory. So when one object takes a write lock, suddenly
the other object can't take a read lock. If we properly had accessed it
through the same object, it would have "just worked".

So it is a bug in our code that we are using >1 object, but we aren't
penalized on Unix because they implement the same behavior we do.
(Taking a read lock on something you already have a write lock on is
fine.) They go a bit further, IIRC, and let you take 2 write locks,
which we *wouldn't* want to allow.

I use Windows primarily for development. The cases that people run into
rarely effect me. I use 'shelve1' for now, though I would like to use
regular 'shelve'. I never try to 'push' a branch into another place on
my filesystem, that is what "bzr branch" (or possibly 'bzr pull').

It would be nice to have them fixed. I've found that I can be perfectly
productive working around them, versus the time it would take me to fix
them.

(I've attempted it a few times.)

There is also the case that if you do "bzr commit" in one terminal, and
then "bzr diff" in another, it will exclude you from doing so, because
of the OS lock. That happens on all platforms, and potentially needs a
different fix. The "easiest" one is to delay the write lock on the file
 until we actually go to do something. But that does introduce race
conditions if someone else starts reading when we become ready to write.

The main time it is encountered is when an editor is brought up for the
commit message, and the user sits in it for a while, and goes to do "bzr
diff" to figure out what to put in the message...

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

iEYEARECAAYFAkpNE6AACgkQJdeBCYSNAANungCgwCD74yUgdz7aYSchNphWf/dZ
4VMAnidNOpViSIQPM7X+icA3aNRVnFP2
=Gb7A
-----END PGP SIGNATURE-----