Re: [Gnu-arch-users] Re: [BUG] FEATURE PLANS: revlib locking

[Tom Lord]

It occurs to me that revlib locking is not, in fact, necessary.
Or rather, it is already available albeit in a strange form.

Suppose that a process needs a revision library tree.   It first
reads the cached inventory and inode cache of that tree.

Now, if it agrees to not access any file not mentioned in that
inventory, and to not trust any file not matching the inode cache,
then everything is safe.  If a concurrent revlib write transaction
tries to delete or re-use the revision in question, and if that
interferes with the parts of the revision our process is looking at,
the inode-cache test will fail and our process will (gracefully) fail.

The only drawback of this approach is that write transactions to
revlibs always take precedence: a write transaction can kill a
concurrent read but a read can not prevent a write transaction from
completing.

Internally to tla we're very nearly there already.   Probably there
are some `vu_open' calls that should be followed up by an inode
check.   Calls to external tools like diff should be followed up by an
inode check.

External tools (which must be read-only) can use something like:

   % tla begin-revlib-txn REVISION > ,tmp

   % if tla end-revlib-txn REVISION ,tmp ; then
       aha, transaction succeeded.
     else
       the revision library revision might have gotten hosed 
       during this transaction
     fi


where `begin-revlib-txn' sets aside the cached index and inode cache
of a revision library revision and `end-revlib-txn' verifies that the
library still matches that.

-t