Andreas L. Delmelle wrote:
-Original Message-
From: Peter B. West [mailto:[EMAIL PROTECTED]
I've been hacking the tree methods in Node recently
...
Are you talking 'maintenance vs. HEAD' here?
No. I realise the message was ambiguous. I was talking about versions
of my general
Peter B. West wrote:
This would be the clean way to express the current version of the code.
However, I am still toying with the idea of allowing (sub)trees to
synchronize on an object passed in as a parameter to the Node
constructor. If the object reference is null, synchronization is turned
-Original Message-
From: Peter B. West [mailto:[EMAIL PROTECTED]
snip /
It also occurred to me that optional synchronization might be a good
idea, allowing a common synchronization object to be passed to the Node
constructor. An alternative was to allow optional synchronization,
Andreas L. Delmelle wrote:
-Original Message-
From: Peter B. West [mailto:[EMAIL PROTECTED]
...
I was worried about increasing the probability of deadlock by having
many more locks held concurrently. Without having thought about it a
great deal, it seems to me that it is easier to
-Original Message-
From: Peter B. West [mailto:[EMAIL PROTECTED]
I've been hacking the tree methods in Node recently, triggered by the
need to construct multiple subtrees during area tree construction,
cobbling them together as necessary. In the original version, I was
able to
I've been hacking the tree methods in Node recently, triggered by the
need to construct multiple subtrees during area tree construction,
cobbling them together as necessary. In the original version, I was
able to synchronize on the Node's containing Tree instance, but that is
no longer
