This is the mail archive of the
mailing list for the libstdc++ project.
Re: [Mingw-w64-public] Thoughts on supporting the C++11 thread library on Windows
2012/5/9 Gabriel Dos Reis <email@example.com>:
> On Wed, May 9, 2012 at 8:39 AM, Jonathan Wakely <firstname.lastname@example.org> wrote:
>> 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
>>> 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.
> We do not seem to have Win32 and Win64 maintainers on the libstdc++
> side. ?That is why I forwarded your message to the WinGW-64 list.
> (We do have maintainers on the compiler side; and they are on the
> MinGW-64 list :-)
> I use Win64 on my windows machines, for some of my programs, but I am
> far from an accomplished Windows programmer and I know just
> enough to be dangerous so I can't take on a Win64 port role.
> However, I do believe a clean Win64 API for C++11 thread is desirable.
> -- Gaby
The cause why I am not that happy about K.Frank's Vista+
"conditionalvariable" API suggestion is that this API isn't backward
compatible. Therefore "win64" as threading-model looks wrong to me,
as it has nothing to do with 64-bit, it is just a OS related API.
Well, introducing here a new thread-model "win64" - we need here a
different name for it - might be still interesting for some of our
mingw users. It would avoid the additional dependency of libgcc to