From: Jonathan W. <jwa...@gm...> - 2012-05-10 14:52:38
|
On 10 May 2012 15:03, K. Frank wrote: > > Neither of these shows --enable-threads of any flavor (in gcc -v), but both > show "Thread model: win32" in the gcc -v output. Yep, if you don't explicitly configure with --enable-threads then the configure script picks a suitable default, which is "win32" on Windows. >> If you use GCC built with --enable-threads=posix then you shouldn't >> need to implement <thread>, it should be provided. > > No, this is not strictly true. Prior to Kai's winpthread implementation > and Ruben's <thread>-enabled build (or the tweaks I made to get > <thread> working), building a windows version of gcc with > --enable-threads=posix won't, in and of itself, give you a working > <thread>. One reason, among others, is that the posix version of > gcc's <thread> relies on the pthreads thread handle being a primitive > integral type. This is not required by the posix standard, but is how > unix / linux pthreads has historically been implemented. However, > pthreads-w32 uses (a pointer to) a struct as its thread handle, Yes, I don't think we have an open bugzilla report about that portability problem, but it's a known issue. > So you either need a little tweak to accommodate this handle > difference, or follow Kai's approach of providing a windows version > of pthreads that uses an integral thread handle (winpthreads). Have those changes come back upstream? It sounds as though they should do. >> The code is all open source, feel free to read it. > > Yes, of course, as a last resort. But it's generally not my first choice. > (By way of analogy, I find it more practical to read the c++11 standard > for <thread>, or ask questions in the c++ news group, rather than read > the gcc source code for <thread>.) That makes sense for <thread> because the standard is the authoritative source. For GCC's configuration the GCC sources are the authoritative source :-) Sorry if my last mail seemed impatient, I do appreciate your feedback based on your own experience of implementing <thread>. |