Re: GTK_OBJECT_DESTROYED

[Owen Taylor <otaylor redhat com>]

Malcolm Tredinnick <malcolm commsecure com au> writes:

> On Sat, Nov 17, 2001 at 08:23:47PM -0500, Owen Taylor wrote:
> [...]
> > Checking the DESTROYED flag is then not useful any more, but worse
> > uses of GTK_OBJECT_DESTROYED() probably indicates code that is
> > assuming that it can detect whether the object has been previously
> > been destroyed with this flag.
> > 
> > Basically, uses of GTK_OBJECT_DESTROYED() probably indicate one of two
> > things:
> > 
> >  a) The caller wants to make sure they don't accidentally 
> >     segfault the object by trying to access freed memory
> >     or other no longer valid state in the widget.
> 
> You seem to indicate that this will still work (in the
> "GTK_OBJECT_DESTROYED is deprecated" world). But if the DESTROYED flag
> has been cleared, it won't, will it? I think I'm confused here. :(

What I'm saying is that all GTK+ widgets shouldn't segfault if
you call arbitrary methods on them after destruction, not that you can
detect destruction this way or that the observed state of the widget
after destruction will actually be _meaningful_.
 
> [...]
> > Unfortunately, these uses usually seem to be in places where people
> > had reentrancy problems, couldn't figure out what was going on and
> > added GTK_OBJECT_DESTROYED() as a band-aid. In the few I've looked at,
> > it is not at all obvious whether GTK_OBJECT_DESTROYED() doing nothing
> > presents a problem or not.
> > 
> > So, if you've used GTK_OBJECT_DESTROYED(), I'd appreciate it if you'd
> > take a look back at your code and see what's the case for that usage.
> 
> There are half a dozen in gnorpm where this is used because window A
> would throw up window B to do something else, then the user would close
> window A forcefully, while window B would close at the end of "something
> else" and continue back in the routine that writes to window A and ...
> oops. :(
> 
> This can probably be worked around by more intelligent handling of the
> ::destroy signal (and generally more intelligent data flow), so it's
> probably not a huge deal, but right now those calls are necessary (they
> fixed a couple of hundred bugs).

Yeah, basically every DESTROYED() check needs to be replaced with
an appropriate connection to ::destroy.

> > My basic opinion is that we probably should remove this macro
> > entirely...  I wouldn't trust any code that was using
> > GTK_OBJECT_DESTROYED() now unless I had carefully checked through it
> > and figured out why it was being used. Leaving it there and
> > non-functional is just turning an immediate painful code reading task
> > into a delayed but even more painful task in debugging.
> 
> Yet another item on the "things to rewrite" list, nothing more drastic
> than that.

Well, we've been trying to keep the "things you must rewrite 
immediately when you port to GTK+-2.0" to a minimum. But then
again the real problem isn't whether we remove the GTK_OBJECT_DESTROYED()
macro or not, but the change in the meaning of ::destroy.

Regards,
                                        Owen