[gclist] Re: gclist-digest V1 #70

[Giuliano Carlini]

Arturo,

>>Even then, I would not trust it until I see a
>>proof and an implementation.
>
>No you don't, 

Marc is right. No algorithm should be trusted without a proof. Too often in 
the past, "obviously correct" algorithms have turned out to be wrong. And 
while tracing the IRG is only a small addition to reference listing, the 
algorithm as a whole is complex enough that it can't be called obvious.

>There are a number of ways to address your point, the formal way is that 
>[A], as any other node can detect a change in the set of objects directly 
>referring to it, and you have to choose a policy to address them, i.e. if 
>while A is waiting for a response from B it notices that a new reference 
>to it (from [M]) has showed up

This is the barrier approach.

>The second way of handling it is implementation related, we don't 
>actually destroy A but we make it drop the remote references that it 
>holds and the remote references to it (the pointer to B in this case), 

How can you do that? If A is reachable, dropping B would be a disaster.

>something that could happen in a network failure or partition, as is 
>usual with distributed programming any object that has to talk to another 
>across a machine boundary needs to be able to cope with failiure.

But you are inducing an unecessary "failure". This is a bug not a failure.

>We could follow a more agressive strategy for cleaning up the cycle by 
>sending terminate messages, but those could be spoofed,

I'm not sure, but I believe that Matt Fuch's addresses this point in his 
paper. Even if it is spoofed, you are still no worse off than you are with 
your algoritm: A has been destructed even though it is reachable. Your basic 
point has merit though: the DGC should be secure from hackers.

g