Hello Ruben and Gabriel! On Sun, May 6, 2012 at 5:15 AM, Ruben Van Boxem <[email protected]> wrote: > 2012/5/6 Gabriel Dos Reis <[email protected]> >> >> Including the mingw64 project about this. >> >> On Sat, May 5, 2012 at 5:59 PM, Jonathan Wakely <[email protected]> >> wrote: >> > For GCC 4.7 I enabled most of <thread> (without timed mutexes) on Mac ... >> > ... >> > If there are any Windows hackers out there who want to improve thread >> > support on their platform please get in touch, I'll be happy to help >> > and advise (although not for the next two weeks as I'm about to go on >> > holiday.) > > There was already talk of and an implementation of vista+ threading stuff. > See this discussion: > http://sourceforge.net/mailarchive/message.php?msg_id=26417059 > I have added the author of this code to the CC list to be sure he picks this > up. I cannot seem to locate any patches he ever sent to the list, but he > claims he got everything working using the "new" win32 threading primitives.
This is mostly just a follow-up to my previous post, where I've tried to summarize some of the windows native <thread> background and issues. > I think an alternative threading model (a new --enable-threads=...) is a bad > idea: this would mean one needs to rebuild GCC twice, make it incompatible > with the normal win32 threading, and essentially release two versions of > every binary you want to release. Better would be an automatic fallback to > handrolled alternatives or plain failures on XP and earlier for the new > stuff. As I said in my earlier post, I have no problem with not supporting pre-vista. (But the value of pre-vista support is really up to the community.) > Perhaps a fallback to a pthreads implementation could work, but that > would make everything dependent on winpthreads (even C code, through > libgcc), which is not that great of an idea. How bad is it to introduce winpthreads as a dependency? As I suggested in my earlier post, it seems like the winpthreads implementation is a sound approach to <thread>. You want to offer pthreads in any event and (as far as I can tell) the winpthreads <thread> implementation is complete and works. What's not to like? > I hope this helps! > > Ruben Cheers! > PS: I have GCC builds utilizing MinGW-w64's winpthreads library and GCC > 4.7's --enable-threads=posix for Windows and AFAICT everything C++11 > threading-related is pretty functional. You can find them here (everything > released after 2010-09 is built with the above posix threading, the 4.6 > versions with the above change backported from 4.7): > http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win32/Personal%20Builds/rubenvb/old/ > There were reports about some problems with Boost (exceptions when there > shouldn't be), definitive performance regression (in non-c++11 code) and the > winpthreads dll being a dependency through the libgcc dll, even for C code, > which is far from ideal, but expected in this setup. 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. Best, K.F. ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ Mingw-w64-public mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
