On Tue, 18 Oct 2011 12:49:43 +1300 "Gavin Lambert" <[email protected]> wrote: > 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.
Anyone who tries to "convert" a Glib::Mutex to a std::mutex, or to terminate a thread with a different call set from the one which created it, deserves everything they get. I can't see any reason why using std::mutex to lock data in a thread created by Glib::Thread::create() should cause any difficulty. It would be extremely difficult to create such a difficulty, as mutexes lie in the kernel. As well as being difficult, it would also be completely perverse for the gcc libstdc++ authors to pervert their system calls so as make std::mutex incompatible with gcc's pthread mutex implementation, and equally perverse for the visual studio authors to make std::mutex incompatible with windows critical sections. Amongst other things, it would make it impossible for programs written for std::thread to call into native windows or unix-like libraries which happen to use their respective native implementations. Chris _______________________________________________ gtkmm-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/gtkmm-list
