Clément Vasseur a écrit :
On Sat, Aug 16, 2008 at 1:50 AM, Clément Vasseur
<[EMAIL PROTECTED]> wrote:
- expose the `GC_GENERAL_REGISTER_DISAPPEARING_LINK' function in neko
in order to let the developper register a "disappearing link", which
will allow the finalization pass to figure out a correct order.
- use `GC_REGISTER_FINALIZER_NO_ORDER' to register the abstract
finalizer, thus allowing the gc to call the finalizers in any order
and release the memory properly.
I just saw a third solution you used in the mysql binding. It looks like
you simulate `GC_GENERAL_REGISTER_DISAPPEARING_LINK' by incrementing the
address by one, thus making it an invalid pointer. This is more clever
than the libgc function because it does not require any additionnal
storage. Is it the way you recommand to do it?
It does require an additionnal alloc_root block, unless you codelogic
ensure that the stored block will never be GC'ed before the main block,
but that's in general hard to claim.
However, I think I will switch to using GC_REGISTER_FINALIZER_NO_ORDER
(which I didn't know) since I think you shouldn't rely on finalization
order (each structure should clean its own memory without needing to
access to the other stored values).
Thanks for raising the topic.
Best,
Nicolas
--
Neko : One VM to run them all
(http://nekovm.org)
