Thanks for the lively discussion! In the end we (Qt 5.0.1 release team) decided to stick with the 'posix' (libwinpthread) toolchain: There's obviously no consensus what do use in the community here, and I personally don't have enough insight to make a really 'informed' decision.
If we get bug reports etc there's still the option to switch in later versions ...
PS: I think it would be help adaptation of the project a lot if things like posix vs win32 threading, and sjlj vs dw2 exception handling (preferably even with an advice what to use by default) would be documented somewhere within the mingw-w64 project site.
> -----Original Message-----
> From: K. Frank [mailto:kfrank29.c@...]
> Sent: Monday, January 21, 2013 3:50 PM
> To: mingw-w64-public@...
> Subject: Re: [Mingw-w64-public] Qt wiki
> Hello niXman!
> I agree with what you are saying.
> On Mon, Jan 21, 2013 at 9:27 AM, niXman <i.nixman@...> wrote:
> >> On top of that, Qt already caters for all the C++11 multithreading classes:
> >> QThread, QMutex, etc... all exist and are probably the ones used in
> >> Qt projects. I'll leave the final decision up to you, but for
> >> stability's sake I'd suggest using plain win32 threading (Qt is used
> >> by a lot of people and it'd suck for people to have a bad MinGW-w64
> experience with it).
> > You say this as if those who use Qt, do not use C++11 and its
> > 'threading support'.
> > I know that winpthreads has some bugs, иut this does not mean that you
> > can not use winpthreads. The less MinGW users will use builds with
> > winpthreads, the fewer bugs will be found and even fewer corrected. If
> > your words said above serve to this purpose, I...hmmm...better say
> > nothing.. =)
> From my perspective, I want to use c++11 / std::thread with Qt, and I am,
> using Ruben's std::thread
> > Kai, I would not recommend to use win32-threads builds, because so the
> > full support for 'C++11 threads support library' will appear only
> > after several years.
> > About the current support for 'C++11 threads support library' in MinGW
> > we can not say that it does not exist or it is not working. It exists,
> > and it works. And I think it works quite well.
> I have not succeeded in breaking mingw-w64's std::thread (based on
> winpthreads) support. I have run basic tests that cover all of the standard
> facilities (mutexes, condition variables, joins, futures, throwing exceptions
> across futures). I'm not saying it's perfect or has no bugs, but I haven't found
> any yet.
> > P.S.
> > the discussed above was about the overhead created by winpthreads.
> > on my own behalf, I would say that this overhead is so insignificant
> > that it is ridiculous to discuss it =)
> From the std::thread perspective, I have identified some overhead caused
> by implementing std::thread on top of winpthreads relative to implementing
> it directly on top of win32, but it is not excessive.
> Also, Kai's winpthreads implementation also outperforms certain facets of
> the native implementation.
> Obviously giving users a "broken" Qt / mingw-w64 experience because of
> winpthreads would be a bad idea. But it works for me. And I agree with
> niXman that if things are working reasonably well (I think they are.), then
> encouraging people to go the winpthreads route will only server to
> strengthen winpthreads.
> > Regards,
> > niXman
> Frank R. Brown
> Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC,
> LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and
> experts. SALE $99.99 this month only -- learn more at:
> Mingw-w64-public mailing list