<br><br><div class="gmail_quote">On Sat, Apr 16, 2011 at 2:05 AM, Matthew Fluet <span dir="ltr"><<a href="mailto:matthew.fluet@gmail.com">matthew.fluet@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im"><br>
</div>Well, the MLton.Finalizable structure is supposed to provide exactly<br>
those guarantees. It uses MLton.Weak under the hood, but in such a<br>
way that the object is not globalized. See<br>
<a href="http://www.mlton.org/MLtonFinalizable" target="_blank">http://www.mlton.org/MLtonFinalizable</a> for an example.<br>
<br>
Indeed, one of the most common "mistakes" made with weak pointers is<br>
trying to make a "Word32.word MLton.Weak.t" object and believe that it<br>
can be used to free a C-side allocated resource; this doesn't work<br>
because the Word32.word is not a heap allocated object (in MLton), and<br>
so is considered always nulled.<br>
</blockquote></div><br>Ah that's good to know. I wasn't sure if
Finalizable had the same problems as Weak. Probably should have also
mentioned the reason I was using Weak and not Finalizable was that
support for weak pointers is more widespread between different
implementations.<br>