Re: GTK_DESTROYED not set after gtk_object_destroy() ?

[murrayc t-online de (Murray Cumming)]

On Mon, 2001-10-08 at 04:26, Havoc Pennington wrote:
> 
> 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 know about that, but I thought that you and Guillaume were in favor of
forcing GC-like memory management on a C++ binding because you thought
that it was somehow a better API. I didn't realize that GTK+ might not
give you the choice.

We've already reluctantly accepted this situation with non-GTK GObjects,
but I don't want to give up on the widgets yet. It's not just that it's
distasteful, but it will make it harder to derive new Gtk-- classes,
because each class will need a specialized 'SmartPointer<> create()'
method.

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.

I'm going to try that - If the C++ wrapper dies before the GTK+ object
is disposed then we'll make sure that GTK+ object doesn't call anything
in the C++ instance. This includes default signal handlers, virtual
functions, and connected signal handlers.

I guess that this could lead to occasional strange behaviour - a widget
could start acting differently if it was implemented in a derived C++
class but then reverted to the original GTK+ implementation when the C++
instance died. But hopefully that will be rare and we can just warn
people that they must use pointers and the gc-like memory management
alternative in these rare cases.


-- 
Murray Cumming
murrayc usa net
www.murrayc.com