Re: nasty bug in multithreaded g_main_loop...

[Tim Janik <timj gtk org>]

On 16 Jan 1999, Owen Taylor wrote:

> b) We destroy sources within the main loop lock. This
>    is nasty because we will end up calling the destroy
>    notifies for the user data within the main lock
>    too.
> 
>    So, considering how that destroy-notify is used
>    in many language bindings (reference counting)
>    you could easily end up with the destructor for
>    some Perl object (for example) being called within 
>    the main loop lock. 
> 
>    And by that time, expecting the application programmer
>    to understand the consequences is a pretty slim
>    chance. (Note that making the main loop lock recursive 
>    does not remove all possible problems here)
> 
>    But avoiding this is not easy, since you first
>    have to disentagle the GHook out of the GHookList,
>    unlock, then destroy the hook. This definitely
>    would require modifications to the GHook API's.
> 
>    (Hmmm, I suppose the cheat is to do all destroy
>    notifications from an idle function... (not really
>    a serious suggestion))

i think the answer to this problem is pretty obvious, you need to call
the hook destroy notifiers without the main loop lock being held.
the only thing that's lacking in the g_hook API to achive this is a
destroy function marshaller, which would actually be pretty consistent
to add to GHookList, since we already feature marshallers for every
other operational bit of the g_hook API.
unfortunately this will require a binary incompatible change ala:

 struct _GHookList
 {
   guint          seq_id;
   guint          hook_size;
   guint          is_setup : 1;
   GHook         *hooks;
   GMemChunk     *hook_memchunk; 
   GHookFreeFunc  hook_free; /* virtual function */
+  GHookFreeFunc  hook_destroy; /* virtual function */
 };

but i think that this is reasonably justified and we need to increase
GLib's version number anyways.


> 
>                                         Owen
> 

---
ciaoTJ