Re: [Mingw-w64-public] Thoughts on supporting the C++11 thread library on Windows

[K. F. <kfr...@gm...>]

Hi Jonathan!

(Again, cross-posted to mingw.)

On Wed, May 9, 2012 at 9:39 AM, Jonathan Wakely <jwa...@gm...> 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
> Windows.

(Done.)

>> 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.


K. Frank