threaded gtk apps / panel stability

[Benedikt Meurer]

Brian J. Tarricone wrote:
> hi all-
> 
> i'm in las vegas now, and they have internet - ah, my withdrawl pains 
> are subsiding (yes, i'm pathetic).  anyway, to the issue at hand....
> 
> On Wed, 11 Aug 2004, Jasper Huijsmans wrote:
> 
> 
>>Benedikt Meurer wrote:
>>
>>>Jasper Huijsmans wrote:
>>>
>>>
>>>>Hey all,
>>>>
>>>>There have been some stability problems with the panel that are possibly
>>>>related to thread usage.
>>>>A different approach to using threads with gtk apps is described here: 
>>>>http://tiago.blogdns.org/gtk_threads.html
>>>>
>>>>Would that be something the panel could use, instead of all the
>>>>gdk_thread_enter()/leave() stuff? No idea if it would be more robust. Any
>>>>ideas? Brian, Benedikt?
>>>
>>>
>>>Kinda nice trick to use g_idle_add()/g_timeout_add() to perform gui 
>>>operations from other threads, tho I doubt that this will be easier to 
>>>handle for panel plugins. I guess it will cause additional confusion for 
>>>the panel plugin writer.
>>>
>>
>>Only the ones using threads, right? This is how it should be, instead of 
>>every plugin writer ;)
> 
> 
> this is odd.  i don't think this page you're linking to is correct.  if 
> you're using g_idle_add() or g_timeout_add() you MUST surround any 
> gtk/gdk calls with gdk_threads_enter/leave() pairs.  glib timeout/idle 
> functions aren't called inside the gdk lock, so....
> 
> and yes, this impacts every plugin writer - whether or not they use 
> threads.

The page says, that you should not make any Gdk/Gtk calls from within 
the other threads, but use g_idle_add/g_timeout_add for this. If you do 
it like this you don't have any concurrency problems with Gdk/Gdk calls, 
cause every Gdk/Gtk call will be executed in the main thread 
(idle/timers will always be executed in the main thread) and so you 
don't need the Gdk lock anywhere.

Benedikt