[Goodies-dev] [Goodies-commits] r1753 - in verve-plugin/trunk: . panel-plugin

[Benedikt Meurer]

Jannis Pohlmann wrote:
> Oh, I think I finally understand how this mutex locking works. The name
> passed to G_LOCK_DEFINE_STATIC, G_LOCK, G_UNLOCK is just an alias to
> identify the mutex, right? At first, I thought it has to be named after
> the variabe which one wants to lock ... 
> 
> Ok, here's what I guess should work.
> 
> verve-plugin.c:
> 
>   G_LOCK_DEFINE_STATIC (plugin_completion_mutex);
> 
>   void
>   verve_plugin_load_completion (VerveEnv* env, gpointer user_data)
>   {
>     VervePlugin *verve = (VervePlugin*) user_data;
>     ...
>     G_LOCK (plugin_completion_mutex);
> 
>     verve->completion = g_completion_new (NULL);
> 
>     /* Add command history to completion */
>     if (G_LIKELY (history != NULL)) 
>       g_completion_add_items (verve->completion, history);
>   
>     /* Add binaries to completion list */
>     if (G_LIKELY (binaries != NULL))
>       g_completion_add_items (verve->completion, binaries);
> 
>     G_UNLOCK (plugin_completion_mutex);
>   }
> 
>   ...
> 
>     g_signal_connect (G_OBJECT (verve_env_get()), "load-binaries",
>       G_CALLBACK (verve_plugin_load_completion), verve);
> 
>   ...
> 
> verve_plugin_load_completion is a callback for reacting on the
> "load-binaries" signal, emitted by the worker thread after it has
> loaded all binary files in $PATH into the completion. 
> 
> Would this work (which I hope ...)?

Looks good. Plus you'll need to protect the read access to the
completion with G_LOCK()/G_UNLOCK().

> And do I need to wrap the
> signal_emit_by_name (in the worker thread) in gdk_threads_enter/leave
> calls?

Only if you are using the global GDK lock, which I don't recommend.

> Regards,
> Jannis

Benedikt