[PATCH] use lockf not flock

[John A Meinel]

It turns out that flock() does not allow you to apply 2 writeonly locks
to the same file, while lockf() does.

I'm a little concerned that this means 2 processes can actually acquire
the same lock. The issue is that lockf() allows you to lock a range of
bytes, while flock() locks the entire file.

So it is certainly possible that lockf() is actually locking 0 bytes.
Though we have seen that 2 processes will hang if the file is write
locked...

Anyway, for whatever mysterious reason if you use flock() on the file,
then repeated flock() calls in the same process will block, causing bzr
to hang (I found that out using baz2bzr). However repeated calls to
lockf() do not hang.

This behavior is not cross platform safe (as far as I know), and we
really should be unlocking our branches when we are done with them.

I actually think we need to look into rewriting Branch() as a
singleton-per-location class. It would figure out what abspath is, and
then keeps a dictionary of currently open Branches, using a weakdict

Is there any reason not to use the singleton pattern? Because when using
bzrlib it is fairly likely that people might hang onto Branch() objects
too long. (or this might just be a silly garbage collector issue in
baz2bzr).

Anyway, the attached patch updates my locking code so that it works with
baz2bzr.

John
=:->

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: use-lockf.patch
Url: https://lists.ubuntu.com/archives/bazaar/attachments/20050525/42eec871/attachment.diff 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 253 bytes
Desc: OpenPGP digital signature
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20050525/42eec871/attachment.pgp