Re: [Gc] When disappearing links are collected before their targets

Ivan Maidanski ivmai at mail.ru
Fri Jan 31 02:20:39 PST 2014


Hi Jim,
Yes, you are right.
It is called dangling link - handled (unregistered) automatically except that if you want to manually free an object with a dissappearing link then you should unregister it manually before free.
Definitely,  documentation should be improved. I'll add info to gc.h.
Thank you
----
Thu, 30 Jan 2014г., 23:37 +04:00 from Jim Pryor <dubiousjim at gmail.com>:
I'm just starting to work with the Boehm GC library, and am trying to
add weakref functionality to a project that already uses the main
functions of the library (including finalizers).
I think I've got a basic understanding of how
GC_general_register_disappearing_link and nearby functions work.
However, I wasn't able to tell from the comments or other documentation
what is the answer to this question:
If I create a disappearing link L to another object O, but then L ends
up being collected before O does, when the time comes around for O to be
collected, we obviously don't in that case want L to still be cleared.
So do I have to manually create a finalizer for L to
GC_unregister_disappearing_link it before it gets collected? Or does the
library take care of this automatically.
Looking at the source (finalizer.c): I haven't fully digested everything
here yet, but superficially at least it looks like the answer to my
question is that the library takes care of this automatically, when it
invokes the function GC_remove_dangling_disappearing_links.
I'm writing the list for two reasons: (1) to invite others to correct me
if I've misunderstood, and (2) to make this question and answer
available to others who might search for it. (I wasn't able to find any
explicit discussion of this in my own searches.) Perhaps (3) it'd be
good to add a sentence or two to the comments in gc.h (or finalize.c)
declaring explicitly that this is the designed behavior, and that one
doesn't need to manually unregister weakrefs on one's own, just before
they're collected.
--
dubiousjim at gmail.com
_______________________________________________
Gc mailing list
Gc at linux.hpl.hp.com
http://www.hpl.hp.com/hosted/linux/mail-archives/gc/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://napali.hpl.hp.com/pipermail/gc/attachments/20140131/94b2f5f2/attachment.htm


More information about the Gc mailing list