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 appreci
> -Original Message-
> From: Peter B. West [mailto:[EMAIL PROTECTED]
> >
> >
> >>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 synchroni
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
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 tree-handl
> -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 t
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 feasibl