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
(Again, cross-posted to mingw.)
On Wed, May 9, 2012 at 9: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.
Okay, that's fair. If you want to mix <thread> with native windows
threads, then a "native" implementation for <thread> makes sense.
Conversely, if you want to mix <thread> with pthreads, then a
pthreads implementation for <thread> makes sense.
Me, I just want to use <thread>, so either way, I don't really care.
(But that's just me.)
>?I guess that's a decision for the mingw maintainers.
Yes, absolutely. As far as I can tell, mingw and mingw-w64 are the
main windows-based "consumers" of gcc. So it's really up to them
as to what support they would like to see incorporated upstream.
So, mingw and mingw-w64 guys, please chime in!
> 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.
Thanks very much for your thoughts and feedback.