This is the mail archive of the libstdc++@gcc.gnu.org mailing list for the libstdc++ project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [Mingw-w64-public] Thoughts on supporting the C++11 thread library on Windows


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>.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]