Re: Can a Multi-Threaded GTKMM Application Use std::thread Rather Than Glib::Thread?

[Chris Gordon-Smith <c gordonsmith gmail com>]

On 17/10/11, Chris Vine wrote:
> On Sun, 16 Oct 2011 23:35:07 +0100
> Chris Gordon-Smith <c gordonsmith gmail com> 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