[MLton] MLton.GC.collect hangs when using MLton.Finalizable

[Matthew Fluet]

Wesley W. Terpstra wrote:
> On Feb 17, 2007, at 3:18 PM, Matthew Fluet wrote:
>> The "bug" is in your usage of Finalizable
> I agree, but I think the bug is that the Ring is not thread-safe. The 
> fact that it could unlink at any time is fine.
> 
>> But, you immediately drop all references to the *container* b, so at 
>> any time, the finalizer could run, and remove b' from the ring.
> Which is what I wanted to happen. The "problem" was that MLton reordered 
> instructions so that the end-of-ring reference was formed before the GC 
> call which preceded it (and should remove it).

I haven't looked at the intermediate code, but fetching the end-of-ring 
reference requires dereferencing the prev reference, which is not a pure 
operation (it depends on the program state).  The point being that MLton 
never common subexpression eliminates an impure operation.

>> In particular, the finalizer could run *during* the loop in fold; 
>> where it removes the end-of-ring reference, leaving fold to run in an 
>> an infinite loop.
> That's not what was happening... However, I fully agree this was a 
> latent bug, closed by adding MLton.Thread.atomically.

So, I agree that MLton.Thread.atomically prevents the finalizer from 
deleting a link while executing the fold.  But, I don't see why adding 
MLton.Thread.atomically would eliminate the Overflow exception if the 
end-of-ring reference were taken before the MLton.GC.collect.