Hi Buben,
I've experienced compilation errors with some Windows "C" headers like
<winnt.h>, <d3dx9.h> etc., as they in this new 4.7.0 release include the
C++ config headers under the bits directory, which always #undef macros
like max() for std C++ headers. Is that expected or unexpected, a bug or a
feature? :p
2012/5/6 Ruben Van Boxem <[email protected]>
> 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
>> > OS X by making the _GLIBCXX_HAS_GTHREADS macro more fine-grained. I
>> > think we could quite easily do the same again for the win32 thread
>> > model (defined in gthr-win32.h) so that <thread> and <mutex> are
>> > available (including timed mutexes), but without <condition_variable>
>> > and <future>.
>> >
>> > It's harder to support <condition_variable> because Windows didn't
>> > provide condition variables until Vista, and even then they interact
>> > with a CRITICAL_SECTION and gthr-win32.h defines mutexes in terms of a
>> > semaphore not a critical section. Douglas Schmidt describes an
>> > implementation of condition variables at
>> > http://www.cs.wustl.edu/~schmidt/win32-cv-1.html but that also
>> > requires mutexes to be critical sections - maybe that could be adapted
>> > to use the gthr-win32.h semaphore-based definition of
>> > __gthread_mutex_t, I haven't looked into it in detail. My suggestion
>> > would be to support <thread> and <mutex> but not <condition_variable>
>> > (or <future> because our implementation uses a
>> > std::condition_variable.) I have some untested implementations of
>> > __gthread_create, __gthread_join etc. if anyone wants to work on
>> > implementing that suggestion. I don't have a Windows machine or
>> > enough free time to do that myself in the near future.
>> >
>> > As a second idea, supporting the full C++11 thread library could be
>> > done by creating a new thread model to be used instead of win32, which
>> > would only be supported on Vista or later and would use Windows
>> > critical sections for std::mutex and Windows condition variables for
>> > std::condition_variable. Critical sections don't support a timed
>> > wait, so that thread model would be similar to the Mac OS X support
>> > and omit timed mutexes. That could easily be solved by implementing
>> > std::timed_mutex as a Windows mutex instead of a critical section, but
>> > that would be difficult in the current Gthreads design because it
>> > follows POSIX and assumes that a timed mutex is exactly the same type
>> > as a non-timed mutex and you just use a different function to wait.
>> > We should consider adding a __gthread_timed_mutex type which can be
>> > different to __gthread_mutex_t, but would be the same type on POSIX
>> > platforms that support the Timeouts option and define
>> > pthread_mutex_timedlock. Again, I have some sketches to make that
>> > work but nothing concrete.
>> >
>> > 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.
>
> 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. 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.
>
> I hope this helps!
>
> Ruben
>
> 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.
>
>
>>
>>
>> ------------------------------------------------------------------------------
>> 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
>>
>
>
>
> ------------------------------------------------------------------------------
> 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
>
>
------------------------------------------------------------------------------
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
