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. ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ Mingw-w64-public mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
