Hello Chris Thanks for this. Yes - I've used Glib::Dispatcher, thanks to a large degree to your posting to this list back in March!
I have used Glib::Thread to give myself a GUI Thread and a simulation thread, so that my GUI remains active even while the simulation is running. I now have a choice if I want to multithread the simulation thread for parallelism. Either I extend the use of Glib::Thread, or I use std::thread, in which case anyone trying to understand my program (including me!) has to understand two threading systems. Chris Gordon-Smith www.simsoup.info On 16/10/11, Chris Vine wrote: > On Sun, 16 Oct 2011 19:44:53 +0100 > Chris Gordon-Smith <[email protected]> wrote: > > My question is: Could I have avoided use of Glib::Thread altogether, > > and just used std::thread? > > You can use C++11 threads fine with glib/glibmm, because the C++ > standard library will almost certainly use the native threading > implementation underneath (pthreads or windows threads) - that is > expected by std::thread::native_handle() - but even if it doesn't, it > will use the same kernel primitives. However, to do anything meaningful > with your program you will probably have to communicate with the thread > running the GTK+ gui from time to time. If you are going to avoid using > the GDK global lock, which is much to be desired, then you will end up > using Glib::Dispatcher, and so glibmm. You will also need to make glib > thread safe by a call to Glib::Thread::init(), although this > requirement will disappear once glib-2.32 comes out. > > This is touched upon by the draft documentation at the end of this now > very lengthy bug report at on glibmm/gtkmm threading at > https://bugzilla.gnome.org/show_bug.cgi?id=512348 , which might give > you some tips, but has become becalmed by a lack of interest. > > Chris > > _______________________________________________ gtkmm-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/gtkmm-list
