[gclist] Releasing symbols and sharing objects

[Charles Fiterman]

At 03:19 PM 11/15/00 -0600, Ken MacLeod wrote:
>I have two situations that I'd like to hear how people handle them.
>I'm using Boehm GC in C.
>
>First, I have a symbol (or flyweight) table where I keep "one" copy of
>each symbol as they are used or created.  Over time, most of the
>symbols will be not referenced by any objects, except for the symbol
>table itself.  How can I recognize this and free those symbols?
>
>Second, I am interfacing my code in C with Perl (and eventually Python
>and other languages) and sharing objects between the two runtimes.  My
>current plan is to maintain a list of "Perl has a copy" pointer
>references (to prevent them being released otherwise), and delete
>these references when Perl deletes the Perl object.  Anybody have
>experience with that, and does it work well?

The following is a comment from our header file and it works very well.

/*
 * If you have called gcDisappearingPtr(link, obj), then *link
 * will be automatically zeroed when the data pointed to by
 * obj becomes inaccessible. This will happen before any finalization
 * occurs.
 *
 * Returns 1 if link was already registered, 0 otherwise.
 *
 * gcDisappearingPtr is often used when implementing weak pointers
 * (pointers that are not traced during collection). By ensuring that
 * the weak pointer is zeroed if the data it is pointing to goes away,
 * the danger of following a loose weak pointer is eliminated.
 *
 * In this case, have link point to a location holding
 * a disguised pointer to obj.  (A pointer inside a "leaf"
 * object is efficiently disguised.) The pointer is zeroed
 * when obj becomes inaccessible. Each link may be registered only
 * once. However, it should be unregistered and reregistered if
 * the pointer is modified to point at a differenct object.
 *
 * Note that obj may be resurrected by another finalizer.
 */
GC_API_FUN(int) gcDisappearingPtr(void ** link, void * obj);
GC_API_FUN(int) gcUnregisterDisappearingPtr(void ** link);

>
>Thanks,
>  -- Ken
>
>