Re: GTK signals and widget destruction/disposal/finalization

[Havoc Pennington <hp redhat com>]

On Tue, 2005-02-08 at 20:00 -0500, Brian Hanley wrote:
> - When does GTK service the event queue? More specifically, what GTK
> calls
>   could be interrupted in order to call callbacks for GTK signals?

Signals are not in any way asynchronous (there are no threads, and they
aren't queued). They are just lists of callbacks invoked synchronously
when the triggering situation occurs.

Sometimes GTK will queue something to an idle handler, such as repaints;
that could involve some signals. But the async there is coming from the
use of an idle handler, signals are still synchronous.

The GTK equivalent of 'event queue' is the GLib main loop. It will
dispatch the GDK event queue, idle handlers, timeouts, IO handlers, and
other 'main loop sources' whenever g_main_loop_run() 
is called. gtk_main() is a wrapper around g_main_loop_run(). The word
'event' in GTK normally refers to the GDK event queue, which is
specifically a queue of events related to the window system. The generic
events mechanism is the main loop.

> - When a widget is destroyed, are children of the widget guaranteed
>   to be destroyed before the parent?

from gtkcontainer.c:

static void
gtk_container_destroy (GtkObject *object)
{
  GtkContainer *container = GTK_CONTAINER (object);
  /* ... elided stuff ... */ 
  gtk_container_foreach (container, (GtkCallback) gtk_widget_destroy,
NULL);
  
So children are destroyed "during" destruction of the parent. Remember
that destroy can be called multiple times.

>  Finalized before the parent?
>   I am assuming the answer to the latter is no, as there is no telling
>   when reference holders will actually drop their references, right?

Exactly.

> - When are GTK signal handlers disconnected from the object?
>   When the object is destroyed? Disposed of? Finalized?

>From gobject.c:
static void
g_object_real_dispose (GObject *object)
{
  guint ref_count;

  g_signal_handlers_destroy (object);

gtk_object_destroy() calls run_dispose() which will thus disconnect
signal handlers. The basic idea is that destroy breaks all links between
an object and other objects.

> - Between the time a widget is destroyed, and the time that "dispose"
>   is called, is it possible for other signals to be serviced? That is,
>   is it best to explicitly disconnect signal handlers before destroying
>   a widget, if you don't want signal handlers called in the interim
>   before finalization?

Should not be needed.

Havoc