Multiple calls to BzrDir.open_branch() return different objects

[John A Meinel]

Robert Collins wrote:
> On Thu, 2006-02-23 at 22:57 -0600, John A Meinel wrote:
>> Because of how locking works, it seems to me that multiple calls to
>> BzrDir.open_branch() or open_repository() or open_working_tree() should
>> return the same object.
>>
>> Otherwise doing:
>>
>> dir = BzrDir.open(path)
>> branch = BzrDir.open_branch()
>> branch.lock()
>> try:
>>   do_something(dir.open_working_tree())
>> finally:
>>   branch.unlock()
>>
>> Will probably cause a deadlock if anything in do_something calls
>> 'wt.branch'.
>>
>> The current code isn't terrible. It just doesn't seem optimal.
> 
> I deliberately did not cache the objects in the bzrdir for a number of
> reasons. Firstly the deadlock issue: there are many ways we can
> deadlock, and this is possibly just the simplest. Other ways include:
> - file system aliasing
> - opening the same bzrdir independently
> 
> Secondly, as we have said in discussion that the 'right way' to access
> things is hierarchically: tree.branch.repository; branch.repository; and
> repository, then the deadlock you describe should be impossible *unless*
> we are violating that precept, and I would actually like to know when we
> violate it as it will help clear up layering problems and make things
> more managable.
> 
> Rob

Well, we have code paths that do "branch.bzrdir.open_working_tree()",
which also violates this. I don't remember exactly why they do, but
doesn't that exact function cause a deadlock? (Because the created
working tree would also create a new branch).

A long time ago I proposed making branches singletons, and it was
rejected because we thought that sometimes people would want to create
to branches referencing the same location. But with the deadlocking
issue it seems like we might want to bring up the discussion again.

I suppose it depends if we want to make the API safe, or 'correct'.
Caching would make it 'safe', so that even poor usage would still work
correctly (most of the time). But your version forces users to code more
'correctly'.

John
=:->


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 249 bytes
Desc: OpenPGP digital signature
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20060227/5b9885d6/attachment.pgp