threaded gtk apps / panel stability

[Benedikt Meurer]

Jasper Huijsmans wrote:
>> 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 ;)

I'm not sure about this.

>> I tend to say 'lets drop the thread stuff from the panel again', it 
>> causes more problems and adds little value. Threaded GUI programming 
>> is always pain. The KDE people realized that years ago.
>>
> 
> I was trying to avoid saying that, but that's my feeling exactly.
> 
>> On the other side I like to be able to use threads in panel plugins, 
>> but if we decide to keep the threaded panel we need to offer either a 
>> good document that describes the changes for plugin writers or we need 
>> a good panel API that hides the difficult stuff from the plugin writer 
>> (too late for 4.2 IMHO). Of course, having both things shouldn't hurt 
>> either :-)
>>
> 
> void xfce_run_gui_function_from_thread (GSourceFunc function,
>                                         gpointer data)
> {
>     g_idle_add (function, data);
> }
> 
> 
> Would that be enough? Combined with a little explanation/example, perhaps.
> 
> Seems so much simpler than constantly locking/unlocking threads that I 
> can't believe it will really work ...

The main problem is that even if the trick works in simple cases (which 
I am sure it does if applied correctly) we will surely run into serious 
problems when it comes to plugins that use 3rd party libraries and call 
functions from another thread. We - and Gtk+/Gdk/Pango/GLib - use 
functions like localtime() and other not thread-safe/reentrant functions 
all over the code, what if the 3rd party library used by a threaded 
plugin uses the same non-reentrant function? Then the panel will surely 
crash and it'll be hard to track the problem. This is just a simple 
example. I guess I could come up with a bunch of other problems that 
arises from a threaded panel and/or threaded panel plugins.

I think the easiest solution to this problem would be to offer a simple 
way for out-of-process plugins that are embedded using the 
GtkPlug/GtkSocket mechanism. This way the panel and the plugin run in 
different processes and the plugin process can use threads or whatever 
he prefers w/o affecting the stability of the panel. This could be 
realised kinda easy with a simple wrapper plugin that, once added to the 
panel, starts the plugin process. We could use D-BUS for the IPC. 
Anyway, too late for 4.2.

The question for now is: Should we release 4.2 with a threaded panel? We 
should be aware that this adds a whole bunch of problems w/o adding any 
value for now, since no of the available plugins use threads ATM.

Benedikt