Re: Dealing with outstanding timeout callbacks

[Braden McDaniel <braden endoframe com>]

On Mon, 2004-11-22 at 23:35 -0500, Braden McDaniel wrote:
> On Sun, 2004-11-21 at 10:54 +0000, Tim Müller wrote:
> > On Sunday 21 November 2004 07:19, Braden McDaniel wrote:
> >
> > > I'm writing a Mozilla plug-in which uses g_timeout_add to add a timeout
> > > callback to drive an animation in a widget. In my widget's destroy
> > > function, I:
> > >
> > >   1. while (gtk_events_pending()) { gtk_main_iteration(); }
> >
> > what's this for? Doing this in a destroy function doesn't look like a 
> > particularly good idea to me.
>
> It's an attempt (probably misguided) to purge any pending attempts to
> redraw the widget. I take it this is a bad idea. Where would this be
> appropriate?
>
> > >   2. Check my stored timeout_id (returned from g_timeout_add): if it is
> > > nonzero, call g_source_remove.
> > >
> > > Yet, there is still an outstanding timeout callback. It runs after my
> > > widget is destroyed, and of course crashes. What do I need to do to run or
> > > remove this callback before my widget is destroyed?
> >
> > nothing really. g_source_remove() should be enough. Maybe you've done
> >
> >   timeout_id = g_timeout_add (...);
> >
> > twice without further checks, and thus leaked the first id?
>
> I call g_timeout_add exactly one place, and there I make sure the
> timeout_id is 0 before doing so. I reset the timeout_id to 0 when the
> timeout callback runs.
>
> But somehow, I guess what you describe must be happening. Still
> investigating.

I think I've figured it out. I am doing

        while (gtk_events_pending()) { gtk_main_iteration(); }

as part of my update loop as well; I do it right before I call
g_timeout_add, in fact. So I yield to process GTK events, one of those
destroys my widget; and poof, there goes the world out from under my
function. But it proceeds to add another timeout because the timeout_id
is 0 (though the timeout_id is freed memory at that point).

So my question is, what's the GTK Way of handling this sort of thing?

-- 
Braden McDaniel                           e-mail: <braden endoframe com>
<http://endoframe.com>                    Jabber: <braden jabber org>