[lldb-dev] [PATCH] Minor lldb_private::ModuleList fixes

[Piotr Rak]

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
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20140324/6bc1297e/attachment.html>