[lldb-dev] [PATCH] Minor lldb_private::ModuleList fixes
piotr.rak at gmail.com
Mon Mar 24 14:05:56 PDT 2014
2014-03-24 21:21 GMT+01:00 Greg Clayton <gclayton at apple.com>:
> On Mar 24, 2014, at 11:36 AM, Piotr Rak <piotr.rak at gmail.com> wrote:
> > Hi,
> > 2014-03-24 17:58 GMT+01:00 Greg Clayton <gclayton at apple.com>:
> > 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
> > 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,
> > For future:
> > Are there any clear guidelines what feature set form C++11 is safe to
> 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.
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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the lldb-dev