|
From: Jonathan W. <jwa...@gm...> - 2012-05-09 13:39:13
|
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. |