Cycling referencing causing memory leak

[Phil Clayton <phil clayton lineone net>]

In creating GTK+ bindings for SML with (supposedly) automatic memory 
management, I found a subtle way that memory was being leaked and no 
obvious neat solution.  As far as I can see, it is an issue when using 
ref/unref from garbage collector hooks where the garbage collector uses 
normal reachability analysis.  I'd be grateful if anyone has any ideas 
or can tell me what I'm missing.

(I recently posted this on gtk-list in response to someone seeing 
similar symptoms, without response.)

The issue occurs when a callback function F is called via a closure C 
that is connected to a signal of an object A where
1. the body of F explicitly refers to A
2. A is an object that does not receive a destroy signal, e.g. 
GtkTextBuffer.
Then, the callback is not automatically disconnected from A as there is 
no destroy signal by 2, so C is not unref'd.  Without unref'ing C, F is 
not unref'd.  By 1, A is not unref'd.  I.e. there is a cycle
  A -> C -> F -> A
Unfortunately, the reachability analysis performed by the garbage 
collector doesn't see this cycle.  Effectively we just have
  C -> F -> A
The garbage collector doesn't know that C still exists just because a 
signal is connected in A.

My current work-around is to have a 'ChildSignal' abstraction, where a 
signal connection also specifies a parent object derived from GtkWidget 
and the signal is disconnected by the parent's destroy signal.

How do other bindings deal with this situation?

Phil