On Mon, 17 Oct 2011 21:57:00 +0100 Chris Gordon-Smith <[email protected]> wrote: > [snip] > So the way ahead for my project is:- > > * Continue using Glib::Thread and Glib::Dispatcher to keep two > separate Glib threads in my program - one for the GUI and one for > the simulation > * If and when I want to multithread the Glib simulation thread to > take advantage of the multi-core processors that are now widely > available, I'll use std::thread > * If and when gtkmm can support multithreading without use of > Glib::Thread, I'll update my program accordingly > > Having two threading systems in the same program adds a bit of > complication, but (assuming its feasible) I think its better than > making the program more reliant on Glib::Thread than is essential. > > I suppose that the two systems should not interfere. From the point of > view of Glib, there will be two threads, a GUI thread and a Simulation > thread. The std threading system will probably not 'know' that there > is a GUI thread. It will just know that it has taken an original > Simulation thread and split it into several parallel ones.
I think you looking at it the wrong way. Threads don't "know" anything, they just share address space. I see no particular reason to split things up as you propose: just use one threading interface or the other for everything. Just make sure you have called Glib::thread_init() if using glib < 2.24, or Glib::thread_init(), g_type_init() or instantiated Gtk::Main if using glib < 2.32, in order to make glib thread safe, and use Glib::Dispatcher for inter-thread communication, and you are ready to go. As it happens I generally don't use either std::thread (to the best of my knowledge g++ doesn't support it properly yet) nor GThreads in my GTK+/glib programs. I normally use pthreads directly, as it does a number of things that GThreads don't do, together with Glib::Dispatcher or things equivalent to Glib::Dispatcher for inter-thread communication. Chris _______________________________________________ gtkmm-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/gtkmm-list
