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

["Gavin Lambert" <gavinl compacsort com>]

Quoth Chris Vine:
> There is no magic to threads.  They are threads of execution started by
> the kernel (in the case of linux, by the clone() call).  Mutexes and
> semaphores are executed in the kernel (in the case of linux by the
> futex system calls).  glibc's pthreads implementation calls into these.
> glib (on unix-like systems) in turn calls into glibc's pthreads.  gcc's
> C11 and C++11's std::thread implementations will probably call into
> glibc's pthreads implemention on unix-like systems also, although I
> guess it is possible that they might go into glibc directly in other
> ways. But they will all use the same kernel primitives

There will be some caveats; despite using the same kernel primitives they
might not be using the same glibc elements, or may tack on additional data.
As such, you probably won't be able to convert a std:: mutex into a Glib::
mutex, although in principle there shouldn't be any problem in using a std::
mutex to wake up a Glib:: thread, or vice versa.  (This may depend on the
specific implementation of the library you use.)

It's also possible that one or the other have particular per-thread init or
cleanup requirements which won't be met by the other (I recall the Win32
days when the CRT got grumpy if you used CreateThread instead of
_beginthread, and MFC got grumpy if you used either instead of
AfxBeginThread); I'm not really familiar enough with either threading model
to say definitively whether this will or won't be an issue here.