The Communication class was trying to (ab)use unique_ptr's atomic properties to protected it from concurrent access. Replace it with a regular reader/writer lock.
Details
Diff Detail
Event Timeline
On the description you mention unique_ptr but I only see shared_ptr here. Was that a typo or do you mean that users of this class kept it behind a unique_ptr?
In any case I think this change is great.
lldb/source/Core/Communication.cpp | ||
---|---|---|
35 | Do you think it's possible that between the call to Clear and this lock someone acquires the lock? |
lldb/source/Core/Communication.cpp | ||
---|---|---|
34–35 | I think this one may be slightly incorrect. Here's how I imagine it going wrong:
I'm not sure how gracefully Connection::Connect handles another connection if not properly disconnected from the first url beforehand. Reading through some of the Connection derived class implementations of Connect I'm not sure exactly what will happen though. The documentation isn't much clearer either... |
lldb/source/Core/Communication.cpp | ||
---|---|---|
35 | Yes, you're both correct. We can't use the ClearUnlocked trick here because it's Disconnect that locks and Clear is virtual. I'll need to play around with this. Maybe we don't need a Clear and we can call DisconnectUnlocked directly ? |
lldb/source/Core/Communication.cpp | ||
---|---|---|
35 | Yeah calling Disconnect in an unlocked fashion would solve that if you called it after locking in Connect. |
lldb/source/Core/ThreadedCommunication.cpp | ||
---|---|---|
63–67 | This wasn't used: nobody called Clear on an instance of ThreadedCommunication. | |
lldb/source/Plugins/Process/MacOSX-Kernel/ProcessKDP.cpp | ||
560 | According to the comment on line 541 this is wrong: // We are running and we can't interrupt a running kernel, so we need to // just close the connection to the kernel and hope for the best m_comm is an instance of CommunicationKDP which didn't override Communication::Clear and hence just called Disconnected. |
LGTM
lldb/source/Core/Communication.cpp | ||
---|---|---|
115–118 | Unrelated to your patch but something about this is triggering my spider sense. Is it possible that status == eConnectionStatusSuccess while WriteUnlocked returns 0? This might end up in an infinite loop then, no? Obviously you don't need to address this since it's unrelated, but something to think about for resiliency. |
I think this one may be slightly incorrect. Here's how I imagine it going wrong:
I'm not sure how gracefully Connection::Connect handles another connection if not properly disconnected from the first url beforehand. Reading through some of the Connection derived class implementations of Connect I'm not sure exactly what will happen though. The documentation isn't much clearer either...