threaded gtk apps / panel stability

[Jasper Huijsmans]

Benedikt Meurer wrote:
...
> 
> 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.
> 

OK, I was afraid of that ;)

> 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.
> 

My thoughts exactly. I used the plugin system, because I was trying to 
be as lightweight as possible accepting that the burden was on the 
plugin writers to ensure stability. With threading I'm sure we can no 
longer hold that position.

For 4.4 we should redesign the panel around GtkPlug/Socket (perhaps 
borrowing from the systray spec) with desktop files describing the 
plugins. A backward compatible 'Legacy plugin' could probably be created 
to load old-style plugins in a GtkPlug. --- Hey, somebody stop me, we 
shouldn't be talking about 4.4, before 4.2 is properly on track to be 
released ;-)

> 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.
> 

Judging from the response and my own feelings on the subject I'd say, 
lets kill it. Then the way to to non-blocking stuff in plugins is to 
spawn a helper app and listen on a pipe or monitor a file or something.

Hollidays being over, I don't know how soon I can do this. Benedikt, 
Brian feel free to rip out the threading support if you do have time 
sooner than I have.

	Jasper