Re: Can a Multi-Threaded GTKMM Application Use std::thread Rather Than Glib::Thread?
- From: Chris Vine <chris cvine freeserve co uk>
- To: Chris Gordon-Smith <c gordonsmith gmail com>
- Cc: GTKmm <gtkmm-list gnome org>
- Subject: Re: Can a Multi-Threaded GTKMM Application Use std::thread Rather Than Glib::Thread?
- Date: Mon, 17 Oct 2011 13:56:28 +0100
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.
] [Thread Prev