[BUG] readonly operations interfere with each other

[John A Meinel]

Aaron Bentley wrote:
> If you invoke "bzr log|less" and then "bzr diff -r 535|less", the diff
> output will be blank until you reach the bottom in the log listing.  I
> assume both operations lock the branch.  It would be handy if you could
> execute two readonly operations at the branch.  The standard semantics:
>
> 1. the read lock can only be acquired when the write lock is not active.
> ~ The read lock can be acquired by several processes simultaneously, and
> is reference-counted.
> 2. the write lock can only be acquired when the read lock is not active.
> ~ The write lock can only be acquired by one process at a time.
>
> Aaron

Can this be solved with .bzr/lock files? Does locking need to be atomic?
Such that you should really use a double directory structure, such as
what Tom suggests here:
http://www.seyza.com/=clients/projmgt-tools/tree/src/iod/csp.html

I'm not really sure how you do multiple reader read locks with that.
Because you really want to have multiple processes holding the read
lock, and it won't go away until *all* of them release it.

If you are dealing with a local filesystem, it seems like you could just
do a normal file, and use the OS's read/write locks.

Since bzr probably won't have a dumbfs storage mechanism for a while, it
seems perfectly reasonable that a server can do the same thing on the
remote side.

This seems reasonable and simple to do. As long as there is an easy way
to know whether a read or a write lock is necessary. Perhaps just have a
singleton Lock() object, which as soon as bzr starts, it acquires the
read lock, and then you can upgrade it to a write lock when necessary.

John
=:->
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 251 bytes
Desc: OpenPGP digital signature
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20050519/0bcd7976/attachment.pgp