Re: GTK_DESTROYED not set after gtk_object_destroy() ?

[Havoc Pennington <hp redhat com>]

murrayc t-online de (Murray Cumming) writes:
> 
> And finalizing is something that happens, but which you can't request,
> right? So there is no way to really kill an object like there was in
> GTK+ 1.2? Then it sounds like we can not use local and class C++ wrapper
> instances, which would be a disaster.
> 

Well, this was basically true in 1.2 as well, it just happened that
you could get away with it most of the time. This was something I
argued with Karl about a lot. ;-) I don't even remember most of the
details myself, though at one point I knew how gtk-- worked in some
detail and may have been more helpful.

I think it might be possible to get the desired gtk-- behavior to
mostly work, but I'd have to look at it again... I don't remember the
code very well.

GTK is designed with garbage collection in mind. A primitive crappy
kind of GC (refcounting), granted, but still GC. And nearly all
languages binding to it are also collected. One of the key things
about GC is that finalization happens at nondeterministic times, and
can't do anything except free memory, i.e. side-effects in destructors
cannot coexist happily with GC since you have no idea when they'll
occur if ever.

So the traditional C/C++ approach to memory management - the "strict
one-owner rule" - clashes in major ways with the semantics of GTK and
other languages.

I'd guess that the basic outline of solving this would be that
deleting the C++ wrapper would free the C++ wrapper, dissociate it
from the C object, return the C object to a sane and valid state, and
also call gtk_object_destroy() to encourage other reference-holders to
let go. That should eliminate segfaults, at least. I remember it being
more complicated than that, but I don't remember what the issues were.

Havoc