[MERGE] Remove generator locks

Aaron Bentley aaron at aaronbentley.com
Sat Apr 26 18:01:15 BST 2008

Hash: SHA1

Hi all,

This patch removes locking from a bunch of generators.  This is an API
break, but not a serious one, as 99% of the calling code will already
have a lock.

As part of my work on fixing fetch-to-rich-root, I discovered that
fetch_missing_text_other_location_fails was consistently generating
warnings about active locks being garbage-collected.  I investigated,
and concluded that it was caused by
Repository.get_data_stream_for_search() taking a lock and then not
releasing it.

There are three main reasons for using generators:
- - To be more responsive
- - To avoid doing work if it proves unnecessary
- - To avoid wasting memory

The second reason is in direct conflict with generators acquiring locks,
or indeed any resource that must be explicitly released.  Since a
generator may not be run to completion, any resource that is held when a
yield statement is encountered may never be released.

So generators that hold locks across a yield statement must be run to
completion.  This is generally not obvious-- it's a tricky kind of API
to use.  I feel it's much better to simply require that the lock be held
by the caller while the generator is in use.

I also removed a few lock decorators.  These are even more useless,
because they acquire the lock, return the generator, and unlock.  They
do not hold the lock during the lifetime of the generator-- in fact,
they release the lock before the generator yields its first value.

Finally, I updated the requisite tests and one caller.

Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

-------------- next part --------------
A non-text attachment was scrubbed...
Name: fetch-locking-3385.patch
Type: text/x-diff
Size: 11685 bytes
Desc: not available
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20080426/81d67864/attachment-0002.bin 

More information about the bazaar mailing list