2013/11/24 Baruch Burstein <bmburstein at gmail dot com>: > I was wondering what the reason was that all implementations of <thread> and > co. mentioned here seem to be by using the GNU implementation over pthreads > and adding a pthread implementation over Win32 threads, instead of directly > implementing these headers over Win32 threads. This seems like an extra > level of indirection, not to mention the whole issue with an extra runtime > dependency. I assume this is for one of the following three reasons: > > 1. It is not easily feasible to implement this over Win32 threads (I am not > to familiar with either the C++11 requirements, or with the Win32 API, so > don't know if this is true) No, that is not the reason. pthread-layer is based on Win32 (what else it should be?!?). So no.
> 2. MinGW64, being a GCC port, prefers to keep as much GCC code as possible, > only adding the porting at the bottom-most layer. If so, while a "native" > implementation would be possible, it is not of interest to the MinGW64 > community. Well, this point sound at least partial true. Of course we have an interest in using upstream-source OOTB, getting it maintained by mainstream without the need to do all the work by ourself. A native implementation nevertheless is of some interest. So there shows up the real issue about such a port. Not all required API is present for all OS-version to be maintained. So we need tons of special-casing, separate testing, ... There is nobody having the time (and interest) in maintaining this in libstdc++ for now. > 3. No one has bothered. No, there were some people asking for native implementation for it. Sadly those people were just demaning, showing private (semi-ready) patches for partial implementation, but nobody of them was actually trying to work upstream for this ... The point about private (none-upstreamed) patches is, that nobody else can post them upstream.due copyright-issues, due review needs, missing testings, etc. > Which is it? Actually it was none of the both points. I spent my time on the new pthread-layer with more liberal license for developers (winpthread), and therefore don't had the time for it and also I don't see a real advantage in adding "native" implementation in libstdc++. winpthread is a native implementation too. User-tests have already shown that overhead caused by it is pretty low. So where is the advantage of doing this? Regards, Kai > -- > ˙uʍop-ǝpısdn sı ɹoʇıuoɯ ɹnoʎ 'sıɥʇ pɐǝɹ uɐɔ noʎ ɟı > > ------------------------------------------------------------------------------ > Shape the Mobile Experience: Free Subscription > Software experts and developers: Be at the forefront of tech innovation. > Intel(R) Software Adrenaline delivers strategic insight and game-changing > conversations that shape the rapidly evolving mobile landscape. Sign up now. > http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk > _______________________________________________ > Mingw-w64-public mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/mingw-w64-public > ------------------------------------------------------------------------------ Shape the Mobile Experience: Free Subscription Software experts and developers: Be at the forefront of tech innovation. Intel(R) Software Adrenaline delivers strategic insight and game-changing conversations that shape the rapidly evolving mobile landscape. Sign up now. http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk _______________________________________________ Mingw-w64-public mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
