2014-03-24 21:21 GMT+01:00 Greg Clayton <[email protected]>: > > On Mar 24, 2014, at 11:36 AM, Piotr Rak <[email protected]> wrote: > > > Hi, > > > > 2014-03-24 17:58 GMT+01:00 Greg Clayton <[email protected]>: > > Note that std::once can be used to enforce "run once" and we don't have > to worry about each platform (like we would have to if we used > pthread_once). > > > > Modified version submitted with: > > > > Author: gclayton > > Date: Mon Mar 24 11:50:33 2014 > > New Revision: 204622 > > > > URL: http://llvm.org/viewvc/llvm-project?rev=204622&view=rev > > Log: > > Modified patch from Piotr Rak that makes GetSharedModuleList() more > thread safe and also fixed a missed member initialization on the copy > contractor and also makes the assignment operator safer. > > > > Modified: > > lldb/trunk/source/Core/ModuleList.cpp > > > > > > Thanks, that's great we can use that, I have not seen any use of > std::once, and that's why I was avoiding it. > > Like I avoided ranged version of for before I have noticed we already > use it. > > I've seen comments about lack of atomic for Windows in debug shared_ptr > implementation, and also we wrap things like mutex, condition variable, > etc... > > > > For future: > > Are there any clear guidelines what feature set form C++11 is safe to > use? > > I would like to eventually switch over to using all the C++11 mutex > classes, but haven't gotten around to it. The C++11 mutex classes would > have also solved the issue you ran into where you want to simultaneously > lock two mutex objects. > > > Or we shouldn't limit ourselves until someone starts screaming out loud? > > We generally need to make sure MSVC implements any C++11 we need. Both GCC > and clang are pretty good at C++11, but MSVC generally doesn't keep up with > the standard as well. > > > Thanks again,
Links from Todd and this clears up things bit more for me. It would be really nice to have things like that as *given* and move the support code to bit higher level threading primitives. However I am not understanding lldb architecture enough to say what would it might look like yet. /P
_______________________________________________ lldb-dev mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
