GSource finalization lock (Re: [Bug 459555] gdk_threads_add_* docs question)

[Tim Janik <timj imendio com>]

On Wed, 22 Aug 2007, gtk+ (bugzilla.gnome.org) wrote:

>  http://bugzilla.gnome.org/show_bug.cgi?id=459555
>
>  gtk+ | gdk | Ver: unspecified
>
> Tim Janik changed:
>
>           What    |Removed                     |Added
> ----------------------------------------------------------------------------
>                 CC|                            |timj gtk org
>             Status|UNCONFIRMED                 |NEW
>     Ever Confirmed|0                           |1

> ------- Comment #1 from Tim Janik  2007-08-22 09:47 UTC -------
> unfortunately the glib main loop mechanism allows sources to be destroyed
> during dispatching (e.g. when a timeout/idler is removed while the gdk lock 
> is
> being held) and also after all GSources have been dispatched (e.g. due to a
> reference count which was held across dispatch()). so whether the gdk lock is
> being held during destroy is unpredictable.

hi Owen.

while writing this comment i had some more thoughts on attempting to
fix the unpredictable lock issue with main loops. do you see compelling
reason to not implement the following?

we defer this code snippet from g_source_unref_internal:
      if (source->source_funcs->finalize)
        source->source_funcs->finalize (source);
      g_slist_free (source->poll_fds);
      source->poll_fds = NULL;
      g_free (source);
for later invocation by keeping a list of need-to-finalize sources
on GMainContext.

this list is to be processed:
- immediately by g_source_destroy if this context is not currently
  in prepare/check/dispatch, i.e. when g_main_current_source()==NULL
- directly after the toplevel source->dispatch() returns, i.e.
  when done dispatching && g_main_depth() == 0.

the above is basically applying the example free_allocated_memory()
technique from the g_main_depth() docs to our GSource finalization problem.
with this we can finally document that there's never any main loop lock
being held (or custom dispatch lock like the one from gdk) during
GSource finallization. however, we will temporarily starve and stack-up
GSource finalizers during recursive main loops.

the question is prolly whether the starving during recursive main loops
can be considered minor enough...

---
ciaoTJ