Op 31 jan. 2011 22:15 schreef "K. Frank" <kfrank29.c@gmail.com> het volgende:
> Hello Ruben (and Kai)!
> On Mon, Jan 31, 2011 at 3:17 PM, Kai Tietz <ktietz70@googlemail.com> wrote:
> > 2011/1/31 Ruben Van Boxem <vanboxem.ruben@gmail.com>:
> >> @Kai: I believe you were working on winpthreads. Would it be OK to integrate
> >> this into libc++ or should this be part of the mingw runtime regardless and
> >> be used/linked like that?
> >
> > I am fine, nevertheless license parts are missing in source (it will
> > have ZPL 2.1 license, which is compatible to (L)GPL as fas as I know)
> > and we need still some testing for it.
> > We still don't have made here final decission, if winpthread will be
> > fixed part of CRT, or if it will be published as separate option
> > library.  For some reason I prefer variant 1, but for shared scenario
> > winpthread need then some improvments, as I dislike to have many
> > instances of it within one application cause by using in EXE and DLLs.

I'll await your final OK then (i.e. Until you're happy with the code ;-)

> I imagine that this would also be true for clang / libc++, although this
> is pure speculation on my part.

Well, Clang uses native Windows threads internally I think, but libc++ was written with pthreads in mind.

> Pthreads is a good api, and people want to use it on windows
> independent of std::thread.  So if winpthreads is on track to become
> part of mingw-w64, then there is not much benefit to providing a native
> (i.e.,  non-pthreads) implementation of std::thread.  It would be mostly
> duplicative effort, and cause confusion by having two incompatible
> implementations.
> Please let me know what you think makes sense.

Well, i don't think C++ std::thread and a C winpthread need any compatibility. Maybe one implementation is more logical for gcc. I would like a native windows way for llvm/clang, it's just... cleaner ;-)

Or: could a runtime check be made to enable a specific backend at startup, using Kai's code on Windows Server 2003-, and Frank's code on Vista+, with a nice pthread interface as you both have now? That's the best of both world IMHO...