[MLton-devel] GC finalization

[Henry Cejtin]

Yes, the way Gtk works is that they use reference counting for their internal
references (a window contains references to the widgets it contains) but user
code  keeps  track  of things on its own.  When the user code is done with an
object, it tells the Gtk world, which then only frees it  if  it  isn't  used
internally.  You need finalization to know when the GC'd heap stops referring
to the object.

I got another note from Allen  describing  more  detail  about  the  Gtk  ref
counting,  and I don't quite see why they need this extra complication of the
`floating reference', although I can imagine some arguments for it.  My  take
is that the way SML-Gtk has to be used is to `manually' keep track of objects
you have a reference to in the heap which are  not  in  any  othe  containing
widget/window,  I.e.,  root objects.  This isn't horrible, but it is bad.  Of
course no worse than doing Gtk programming in C,  but  certainly  worse  than
doing it in Python for instance.

>From  the earlier E-mail from Allen I would say that he is there now, or else
I would have expected some other response when I asked him to  say  hello  to
Andrew.

>From leunga@amanda.dorsai.org  Thu Jun 13 09:58:14 2002
>Date: Thu, 13 Jun 2002 10:58:12 -0400
>From: leunga@dorsai.org
>To: Henry Cejtin <henry@sourcelight.com>
>Cc: leunga@dorsai.org
>Subject: Re: re SML-Gtk question
>
>On Wed, Jun 12, 2002 at 11:51:49PM -0500, Henry Cejtin wrote:
>>I would have thought that the Gtk stuff would automatically keep track of its
>>own references, (widget to widget), but would leave the C code to keep  track
>>of  its  references  to objects.  
>>Something like this must be going on since,
>>for instance, Python, with its own reference-counting scheme, interacts  well
>>with Gtk and doesn't seem to leak.
>>If  they  are  sane,  always in question for people using reference counting,
>>then something like *_new would return an object with a reference count of 1.
>>Then there is the question of if adding the result to another widget requires
>>you to increase the count, or if that is done for you.  
>>It's all a bit silly,
>>but  it  still  seems to me that once you unravel what their conventions are,
>>finalization is enough to make it live with a properly GC'd  world.   
>
>   The following seems to be gtk's protocol:
>
>   1.  An object has a reference count (from other widgets) and a 
>   2.  floating reference flag.
>
>   When a normal widget object is created, it has rc = 0 and 
>   floating reference flag = true.   A toplevel widget (like a window) 
>   has rc=1 and is non floating initially.  
>   Adding a widget w1 to w2 involves incrementing the rc of w1 
>   and unsetting its floating reference flag.
>
>   For example, we can have:
>
>      val w = gtk_window_new(GTK_TOP_LEVEL)
>      val b = gtk_button_new_with_label("foo")
>      val _ = gtk_container_add(w, b) /* w and b are dead in sml world, but
>                                         both are live in C world with rc=1 */
>      val _ = gtk_main() 
>
>   or:
>
>      val w = gtk_window_new(GTK_TOP_LEVEL) 
>           /* w is dead in sml world but has rc=1 and should not be freed */
>      val b = gtk_button_new_with_label("foo")
>             /* b dead in sml world, has rc=0 and is floating;
>                it should be freed by sml's gc. */ 
>      val _ = gtk_main() 
>      
>   I guess here's one way to use finalizers in SML:
>
>       If the finalized widget is floating and has rc=0 then destroy it.
>       Otherwise, do nothing (because it's being managed in the C world).
>
>>Without
>>it  it must be the case that a program that just loops creating new top-level
>>windows (or buttons for a window) which it then destroys is going to leak.
>
>>With regards to having to move from SML/NJ to OCaml, that would  really  hurt
>>me.  The implementation of OCaml is very nice, but the syntax (like having to
>>declare  records)  and  circular  lists  being  allowed  would  really  hurt.
>>Definitely  another  example  of  how  MLton  needs  finalization.  I'll send
>>Stephen Weeks another vote in that direction.
>>
>>Thanks again

_______________________________________________________________

Don't miss the 2002 Sprint PCS Application Developer's Conference
August 25-28 in Las Vegas - http://devcon.sprintpcs.com/adp/index.cfm?source=osdntextlink

_______________________________________________
MLton-devel mailing list
MLton-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mlton-devel