Hi,
As you may know we currently have a package in the Fedora MinGW package
collection named mingw-pthreads. This is a library which implements the
pthreads API. Internally it wraps the pthreads API to native Win32 API
threading functions. This library can be used to allow more easy porting
of applications to Windows.
Currently this implementation of the pthreads API lacks certain features
which prevent it from being used by gcc to enable certain modern C++11
features.
Therefore upstream mingw-w64 developers have been working on a new
pthreads library which resolves these shortcomings in the original
pthreads-win32 library. This new library is called winpthreads and is
hosted on the mingw-w64 SVN repository. When using winpthreads as
default pthreads API implementation we can enable features like
std::thread in gcc.
The mingw-w64 developers have recently moved the winpthreads library
from the 'experimental' branch to the 'trunk' branch to give it more
exposure for testing. As our mingw toolchain is based on mingw-w64 trunk
snapshots we should consider using winpthreads.
For Fedora 20 (scheduled fall 2013) I'm considering to replace the old
mingw-pthreads package with the winpthreads library and enabling C++11
features like std::thread in gcc
However there is one big downside to this. Once we tell gcc to use
winpthreads (or better said: the configure flag --enable-threads=posix)
it will cause all binaries which are built using this compiler to
automatically depend on the winpthreads shared library (DLL). Even when
you build a simple 'hello world' you'll also need to redistribute the
winpthreads DLL along with your program to be able to execute it.
We could perform this migration in two separate steps:
1. replace the old pthreads-win32 implementation with winpthreads
and have all pthreads-using packages rebuilt against it
2. build mingw-gcc with --enable-threads=posix
Step 1 only affects packages which directly use pthreads.
Step 2 is needed to allow applications to use C++11 std::thread
What are your thoughts about introducing winpthreads in Fedora and
having gcc use it by default? I personally think that Fedora 20 is a
good target for this. If it turns out that it causes too much issues
then we still have enough time to do the necessary reverts well before
Fedora 20 is released (fall 2013).
Regards,
Erik van Pienbroek