Op 19 sep. 2011 01:08 schreef "K. Frank" <[email protected]> het volgende: > > Hello Venu! > > I have taken the liberty of copying this post to the mingw-w64 list, > as it's relevant there, as well. > > On Sun, Sep 18, 2011 at 4:18 PM, veegee <[email protected]> wrote: > > > > Hi K. Frank: > > > >>> To follow up on an earlier suggestion in this thread: Why not use the > >>> standard > >>> std::thread facilities of the upcoming c++0x standard? (Unless you want > >>> to > >>> restrict yourself to c, rather than c++, which I don't think is an issue, > >>> based > >>> on the preceding discussion.) That would seem to be the > >>> "forward-looking" way > >>>to go, and you won't have to write your own os-dependent threading > > wrappers. > >>> std::thread works out-of-the-box with recent g++ versions on linux. > >>> It is alleged to work on windows using mingw-w64, a project distinct > >>> from, but > >>> similar to mingw: > >>> http://sourceforge.net/mailarchive/message.php?msg_id=28014252 > > > > This is absolutely what I want to do. As you indicate, support for c++0x > > standard is > > available generally on linux, but not on Windows or Mac. > > If you're willing to use mingw-w64, I believe that std::thread *is* supported > on windows.
There are *experimental* GCC 4.7 and 4.6 builds available, but for now only linking with "-static" works. GCC 4.6: http://code.google.com/p/pcxprj/downloads/detail?name=MinGW_gcc4.6.2.20110826_static_enable_std_thread_test.7z&can=2&q= GCC 4.7: http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win64/Personal%20Builds/rubenvb/and http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win32/Personal%20Builds/rubenvb/ > > > As soon as it is > > supported officially, I will throw my wrappers into the garbage can and > > happily re-code to use > > std:thread. > > I believe that the mingw-w64 support of std::thread is official, but perhaps > someone from the mingw-w64 list could comment on this so that I don't > put words in anyone's mouth. It's not fully functional yet (libstdc++ dll throws an uncaught exception, link with -static to work around this), so I'd hardly say it's official support... Work is being done on getting it working completely and correctly :-) > > >>> It is also easy to patch mingw to get std::thread working (basically > >>> relying on > >>> pthreads-win32 to take advantage of the pthreads implementation of > >>> std::thread > >>> that ships with recent versions of gcc, at the cost of becoming dependent > >>> on > >>> the pthreads dll). You can see my earlier thread on this here: > >>> http://sourceforge.net/mailarchive/message.php?msg_id=26533138 > >>> K. Frank > > > > Nice work on using pthreads-win32 to get a std::thread working on mingw. > > Since I am > > stubbornly insisting on not including pthread-win32 (which, by the way, has > > nothing to do > > with its technical merits - I think it is a great piece of work), I can't do > > what you describe > > in your patch article. > > Well, it depends on what your issue with pthreads-win32 is. As I understand > it, the mingw-w64 team (who should correct me if I'm wrong) wanted 1) to > have the pthread handle be a scalar type (as it is in most (all?) unix > implementations, but not in pthreads-win32), and 2) avoid some of the > licensing issues that arise with pthreads-win32. So they wrote their own > pthreads implementation for windows (winpthreads I think they call it). If > mingw-w64's winpthreads resolves any of your issues with pthreads-win32, > you can get std::thread out of the box with mingw-w64 (as I understand it, > not having tried it myself yet). > > > Perhaps I should re-write my wrappers to look like > > std::thread? Or > > help you with mods to your files to eliminate the dependency on > > pthreads-win32? > > I have implemented a native windows version of std::thread for g++ > (mingw and mingw-w64). It is native in the sense that it the various > std::thread facilities are implemented directly in terms of the windows > api without going through a pthreads-like layer (and, in particular, through > neither pthreads-win32 nor winpthreads). You can see some discussion > of it here: > > http://sourceforge.net/mailarchive/message.php?msg_id=26417080 > > Note that this implementation would require vista or later, because, among > other things, it uses windows condition variables. > > It has the advantage that it doesn't use pthreads, so it gets rid of a layer > between std::thread and the underlying windows os. But it has the > disadvantage that it doesn't use (or implement) pthreads, so it doesn't > provide a threading solution for code that uses pthreads. (And, of course, > lots of code uses pthreads, and hardly any code uses std::thread (yet).) > > Right now this implementation exists as a locally patched versions of > mingw and mingw-w64, but has not been integrated into the gcc (or > mingw / mingw-w64) code base or packaged as patches that can be > applied to that code base. > > If this sort of implementation (which is less mature than the pthreads-based > solutions) would be of use to you, I'd be happy to work with you to help > adapt it to your needs. But in the best of all worlds, I'd hope that we could > structure any such effort to be of use to a broader audience. Why not use portable boost:: thread in the meantime? It's naturally very similar to the c++11 version, and is a nice abstraction of platform threads. I also don't see any problem in using pthreads, except that it is very low-level. Winpthreads takes care of any licensing worries you may have with pthreads-win32 and is actively developed, do problems you may encounter are fixed quickly. Ruben > > Best. > > > K. Frank > > ------------------------------------------------------------------------------ > BlackBerry® DevCon Americas, Oct. 18-20, San Francisco, CA > http://p.sf.net/sfu/rim-devcon-copy2 > _______________________________________________ > Mingw-w64-public mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
------------------------------------------------------------------------------ BlackBerry® DevCon Americas, Oct. 18-20, San Francisco, CA Learn about the latest advances in developing for the BlackBerry® mobile platform with sessions, labs & more. See new tools and technologies. Register for BlackBerry® DevCon today! http://p.sf.net/sfu/rim-devcon-copy1
_______________________________________________ Mingw-w64-public mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
