Re: [Vala] Running Gtk.main() in a separate thread

[Evan Nemerson <evan coeus-group com>]

On Fri, 2016-10-14 at 13:12 +0300, Dmitry Golovin wrote:
> Hi all!
>
> I want to create a modular application with libpeas. One of it's
> modules is a GTK+ user interface. The problem is that the user
> interface should run in a separate thread, so the main application
> will continue it's execution. The threads should be managed in the
> extension code, not the main application's code.
> So basically what I need is to start Gtk.main() in separate thread.
> Evan said yesterday that this would be a bad design, so if it is
> possible to make it better, please share your thoughts.

I don't necessarily think it's a bad design, it just may not match
GLib/GTK+'s expectations.  I don't have a lot of experience it this
area (I've always been able to use the default thread), but…

The problem is the main event loop.  It's possible to run it in a
thread other than the main one, but you'll probably have to set the
thread's default main context (see the docs
for g_main_context_push_thread_default/GLib.MainContext.push_thread_def
ault).  Otherwise lots of stuff will not work correctly; for example,
GLib.Idle.add may end up using the wrong context.

If I were you I would look into the possibility of using the default
thread for GLib's main loop, and moving whatever you're currently doing
in the main thread to another thread.  This will probably also make
your life a lot easier if you want to use async elsewhere in your code;
running without a main loop cripples a lot of nice functionality in
GIO.

If what is currently in your main thread is using an event loop, you
could also integrate glib's main loop into it or, if it supports it,
integrate it into glib's main loop.  My understanding is that this can
get a bit gnarly, but GLib does expose the necessary APIs.

Finally, you could just spawn a separate process for the GTK+ UI,
though that would likely require some sort of RPC layer.


-E