[Gtk-sharp-list] widget destruction

[Mike Kestner]

2011/3/7 Nicholas Frechette <zeno490 at gmail.com>

> If we want to bring up the debate of how gtk resources are destroyed, I
> would strongly like to suggest _NOT_ piggy backing on the finalizers to
> garbage collect GTK objects.
> This will play very poorly with the GC heuristics.
> GTK native resources should use the same practices that the rest of the
> C#/.net community uses: explicit usage of the dispose pattern.


Another voice in the choir.  For the record, my reluctance on this is an
equally strong practice in the Gtk+ community: the use of an explicit
Destroy pattern.  I think if we are going to make Dispose mean Destroy in
3.0, we'll probably need to completely remove the Destroy methods to avoid
confusion, and that will probably be a big API break for existing codebases.
 Everyone seems to be arguing for it, though.

To highlight why I do not like the current behavior:
> 1- Create a bunch of widgets
> 2- Manually remove their references
> 3- GC kicks in and marks those objects as "dead" and queues them up for the
> execution of their finalizers
> 4- The gtk object finalizers executes, which adds again a reference to that
> object so that the GTK main thread can release it
> 5- The gtk main thread picks up the queued objects for destruction and
> destroys them
> 6- GC runs again and marks those objects as "dead" and queues them up for
> the execution of their finalizers
> 7- The gtk objects finalizers execute and since the is no more work to be
> done, the object is finally destroyed and its memory reclaimed
>
> The "clever" use of the finalizer in step 4, in a multi generational GC
> heap, will move that object to a longer lived heap and it will take
> potentially MUCH longer for step 6 to run on that longer lived heap. You are
> effectively promoting soon to be dead objects to a long life object heap
> which means their memory will linger in "use" much longer than it would need
> to.
>

Your analysis doesn't really track.  Dispose invokes GC.SuppressFinalize, so
an explicitly Disposed, or Destroyed as is proper in 2.12, Object will never
run the finalizer.

It would make much more sense to have the finalizer simply check if the
> object has been disposed of manually and emit a warning that the application
> is leaking GTK memory instead of circumventing the proper flow of things.
> Perhaps that check could only be in debug as well, reducing the overhead in
> release/final builds.
>

This thread has kind of gone a little far afield from the user's original
post, but I guess I can reply to this the same way as the original.  If you
have a sample that profiles as leaking Destroyed objects, I'd be happy to
take a look.  Otherwise, this is a theoretical discussion about what I
consider working code until someone proves otherwise to me.

Mike
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ximian.com/pipermail/gtk-sharp-list/attachments/20110307/5b3c140f/attachment.html