[RFC] locking decorators and iterators

[Robert Collins]

I ran into a nice bug today, and its structural in our code.

In short:
extras = tree.extras()
tree.add('foo')
'foo' in extras => True

This is because while extras() requires a read lock, and even takes one,
the lock expires before any code from extras() executes: calling the
method simply creates the iterator object. tree.add() then replaces the
inventory attribute on the tree object during its write lock, and when
you execute 'foo' in extras - finally at this point it looks at the
current tree inventory.

After a conversation with Andrew about this, I have several things to
suggest. I think our needs_*_lock decorators should check, and complain,
if the function they are decorating is a generator. This can be done at
load time, and should be very fast. The reason is that these decorators
are ineffective on generators.

Secondly, I wonder if we should just start returning lists, to avoid
such race conditions as that above.

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/20070213/46e0fc13/attachment.pgp