Submitted here:
```
svn commit
Sendinginclude/lldb/Core/Communication.h
Sendinginclude/lldb/Core/ConnectionFileDescriptor.h
Sendinginclude/lldb/Target/Process.h
Sendingsource/Plugins/Process/FreeBSD/ProcessFreeBSD.cpp
Sendingsource/Plugins/Process/POSIX/Proce
All good - I just wanted to double check since I jumped the gun on Jason
last time I took it the wrong way :-)
On Mon, Sep 15, 2014 at 11:06 AM, Jim Ingham wrote:
> Sorry if I wasn’t clear, this looks fine. Check it in.
>
> Jim
>
> On Sep 15, 2014, at 7:55 AM, Todd Fiala wrote:
>
> Hey Jim,
>
Hey Jim,
Just for clarification, is this a LGTM? Or are you wanting Shawn to spend
more time looking at the bigger picture behind some of the locking?
-Todd
On Fri, Sep 12, 2014 at 12:37 PM, wrote:
> That looks okay. Thanks for looking at this. Seems to me that if you're
> only synchronizat
That looks okay. Thanks for looking at this. Seems to me that if you're only
synchronization is locking access to some flag, then you're either doing
something fairly weak (like the log example) or missing some real
synchronization... So it's worth viewing the necessity of the change with
sk
Hi Jim, thanks for the feedback.
I agree these may fall into the category of 'formally correct, but not strictly
necessary.' One good thing is it makes clear the intention these variables are
being directly accessed from multiple threads.
Something I noticed about thread sanitizer is that it w
This seems like an incomplete solution to the problem that the thread sanitizer
might have uncovered.
In the case of m_shutting_down, this flag is advisory, and really means don't
start any new work because I am going to shut down. Then there's a mutex to
make sure that the work of kicking a
There are several places where multiple threads are accessing the same
variables simultaneously without any kind of protection. I propose using
std::atomic<> to make it safer. I did a special build of lldb, using the
google tool 'thread sanitizer' which identified many cases of multiple thread
