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 7 May 2012 18:35, K. Frank wrote:
> Hello Ruben and Gabriel!

N.B. I'm not on the mingw lists, so please keep me CC'd if you want
responses or any help from me in enhancing libstdc++ to work better on
Windows.


> And my P.S.: ?As I mentioned in my earlier post, I have been using Ruben's
> <thread>-enabled build, and it passes all of my tests. ?So the approach of
> sticking with the winpthreads implementation of <thread> and directing
> any available manpower to fixing and/or improving it rather than to building
> a separate implementation seems on the surface sensible.

The C++11 thread library exposes native OS handle via the
"native_handle()" member functions.  A <thread> implementation based
on Windows thread primitives would allow mixing std::thread with
WaitForMultipleObjects, which may be preferable to people who want to
use mingw's std::thread and combine it with their own code.  I don't
know if such people exist, I never use Windows except to run Putty to
connect to GNU/Linux hosts.  If no mingw users care about
--enable-threads=win32 and don't want a new --enable-threads=win64
then yes, just using --enable-threads=posix and winpthreads seems
sensible.  I guess that's a decision for the mingw maintainers.

If however, users want --enable-threads=win32, then my first
suggestion seems like a reasonable way to give them a better
experience than they have today.


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