On 17/10/11, Chris Vine wrote: > On Sun, 16 Oct 2011 23:35:07 +0100 > Chris Gordon-Smith <[email protected]> wrote: > > 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. > > Since we now have an approved C11 standard (passed its ballot and > awaiting ISO publication) as well as a C++11 standard (just recently > formally published), each with threading and memory consistency > models which deliberately map onto each other, the proper approach > would probably now be for glib to drop its own threading > implementation. > > I don't necessarily see that happening in the near future, if only > to avoid glib API breakage, but it argues against a "my way or the > highway" approach by glib to threading, something which it appears > just recently to have avoided. > > You will find very little difficulty moving between glibmm threads > and C++11 threads if you keep away from such things as > futures/promises, or for that matter in moving between > pthread/Gthreads and C threads. Programmers used to the windows > threading API will have more work to do. > > Chris
Thanks. This makes sense to me. I agree that Glib should eventually drop its own threading implemention. As things stand now, the requirement for GTKmm programmers to use Glib::Thread impedes the adoption of the standard - std::thread. 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. Incidentally, while I was working out how to use Glib::Dispatcher, I made a little test program. If anyone is interested, its at http://www.simsoup.info/SimSoup/GUI_With_Worker_Threads.html Regards Chris Gordon-Smith www.simsoup.info _______________________________________________ gtkmm-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/gtkmm-list
