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 _______________________________________________ vala-list mailing list [email protected] https://mail.gnome.org/mailman/listinfo/vala-list
