Re: Gtk3 and threads

[Thierry Vignaud <thierry vignaud gmail com>]

On 19 May 2014 10:03, Daniel Kasak <d j kasak dk gmail com> wrote:
> I'm attempting to use threads in a Gtk3 app. It's basically working (
> proof-of-concept anyway ), but I get a segfault when exiting. Why am I using
> threads? I'm adding support for triggering ( long-running ) commands on a
> remote server, via Net::SSH2. I want to capture the output and display it,
> as it is generated, in the GUI. I'm planning on using a single shared
> variable for this - an array that the child thread will append to. Then in
> the main thread, I'll set up a timer, and push new lines of output into the
> GUI. Something like that anyway.
>
> When I close the last window, and call Gtk3::main_quit() ... I get:
>
> Base_UI::close_window called in thread [0]
> Last window closed ... exiting ...
> GLib-GObject-CRITICAL **: g_object_get_qdata: assertion 'G_IS_OBJECT
> (object)' failed during global destruction.
> GLib-GObject-CRITICAL **: g_object_steal_qdata: assertion 'G_IS_OBJECT
> (object)' failed during global destruction.
> GLib-GObject-CRITICAL **: g_object_unref: assertion 'G_IS_OBJECT (object)'
> failed during global destruction.
>
> These 3 GLib-GObject lines are repeated many times. Then finally:
>
> Segmentation fault

showing your code could help but using threads is not easy.
Either you confine all your GUI stuff to one thread or you have
to make sure there's only one thread using gtk+ at a time

Note also that there's issues with glib that might be related:
It creates threads under our neck and they may well call gtk code.
It notably creates threads for network related stuff.

Why it's bad? Think about:
- at_exit() calls that register actions
- signals that land in glib threads
  (I suffered quite a lot with SIG_CHLD)

There're other libraries that create threads behind our back (eg: webkit)

The more, the merrier... :-(

It can make single thread apps to segfault.
So for a mulithread app...