branch locking mk2.

[Robert Collins]

Martin mentioned doing a new lock type on list a few days back, I have
chatted with him about that, and his ideas. The follow is a brain dump
of that for discussion and what we think would be nice for discussion,
critique etc.


A side note, but an important one : this cannot simply replace the
existing locks, we need to keeo the current lock code for compatibility
with extant clients. It requires a format change to each object that
uses this to introduce it.


The desired characteristics are:
* Locks are not reentrant
* Stale locks can be guessed at by a heuristic
* Lost locks can be broken by any client
* Failed lock operations leave little or no mess
* Deadlocks are avoided by having a timeout always in use, clients
desiring indefinite waits can retry or set a silly big timeout.


Proposed implementation [this is a sketch - details subject to
refinement (and tweaked from what we discussed as I realised some minor
issues while typing)]:
where a lock called 'foo' is desired, we make a directory:
foo/

which always has subdirs pending and released:
foo/
foo/pending/
foo/released/

and if the lock is current held an owner:
foo/
foo/locked/details.txt
foo/pending/
foo/released/

To take out a lock, make a temporary dir with a random name in pending,
and write a lock object to details.txt in that dir using the 'rio'
format. Details that are required are 'name', 'time' and possibly
hostname/pid. Then rename that temporary dir to foo/locked.

To remove the lock rename the directory locked to
foo/released/temporary-name, and then delete the details.txt and the
random dir name.

This is robust - AFAWK on all fs's directory renames are atomic and you
cannot get two competing successes. If we are worried that we can get
that, we can read details.txt to ensure its the right one.

If a pending lock is removed the rename into the lock dir fails, so
pruning noise in the pending dir is safe.

Similarly a communications error during lock release will at most
prevent it being released (the rename fails), or prevent cleanup after
its released, in which case everything in released/ can be considered
temp files to be removed whenever they are noticed.

Stale locks can be guessed at by the datestamp on the file if the server
has one, or the datestamp in the details.txt rio output.

A possible future enhancement would be to add a 'last-used.txt' file as
a heartbeat, to enhance the reliability of stale lock detection, but
Martin thinks this is not needed for a first cut of the system, and I
agree.

Performance wise taking a lock is three roundtrips:
mkdir
write details.txt
rename

and releasing is also three roundtrips:
rename
rm details.txt
rmdir


Thoughts? 
Rob



-- 
GPG key available at: <http://www.robertcollins.net/keys.txt>.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20060208/84a3806d/attachment.pgp