Hello Luis! On Mon, Aug 6, 2012 at 3:08 PM, Luis Lavena <[email protected]> wrote: > Hello, > > A few months ago there was a conversation on this list about an > improved threading model that will avoid the dependency on > pthread-like wrappers.
Would this be the discussion started by Jonathan Wakely: http://gcc.gnu.org/ml/libstdc++/2012-05/msg00020.html that was largely cross-posted to this (the mingw-w64-public) list: http://sourceforge.net/mailarchive/message.php?msg_id=29240313 ? > Sometimes it was referenced as win64, which a few developers > considered it wrong and that "win32" threading should be enhanced > instead. > > Either way, wanted to follow up that conversation and see if someone > is working on that and offering my mindless assistance testing things > out across different projects. I don't know whether there is any further effort in this direction over in the gnu-libstdc++ community. As far as mingw-w64 goes, I believe I was the only one who explored this approach, but after putting together the prototype native-windows std::thread implementation mentioned in the thread cited above, I haven't followed up on any of this. With the advent of winpthreads and Ruben's std::thread-enabled builds, I haven't felt any personal need to continue the native-windows approach. > While winpthread work is great and has enabled C++ thread work on > Windows, I still believe a non-posix wrapper approach can be obtained. Indeed it can; my prototype implementation does so. But what is it that you hope to achieve? Although there have been some reports of issues with winpthreads, it seems to be basically all there, is actively supported Kai Tietz, and Ruben's std::thread-enabled build based on winpthreads passed all of my (by no means exhaustive) std::thread tests. (I should emphasize that if you want to use the native windows threading api in your mingw-w64-compiled code, that's been possible already for quite some time. What's at issue here is what underlying threading api is used to implement std::thread -- windows or pthreads.) Is there something you're missing or some efficiency issue? Is there a licensing issue? (I think part of the motivation for writing winpthreads was to avoid certain licensing issues with pthreads-win32.) I certainly don't pretend to speak for Kai and Friends, but I would expect that they would be open to addressing any reasonable issues you have. I would be happy to work with anyone who wants to integrate the native-windows std::thread implementation into the gcc / mingw / mingw-w64 proper, but it seems to me that efforts in that direction would be duplicative of what is going on with winpthreads. > Thank you in advance for your time. > -- > Luis Lavena > AREA 17 Best. K. Frank ------------------------------------------------------------------------------ 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
