This commit removes the stdio forwarding thread in lldb-server in favor of a MainLoop callback.
As in some situations we need to forcibly flush the stream ( => Read() is called from multiple
places) and we still have multiple threads, I have had to additionally protect the communication
instance with a mutex.
Details
Diff Detail
- Repository
- rL LLVM
Event Timeline
Please see my comments.
source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerLLGS.cpp | ||
---|---|---|
940 ↗ | (On Diff #30001) | m_stdio_communication.Disconnect() ? |
967 ↗ | (On Diff #30001) | If SendProcessOutput is called from ProcessStateChanged within Monitor thread context we may have a race here:
|
source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerLLGS.cpp | ||
---|---|---|
940 ↗ | (On Diff #30001) | Added. Note that this will probably send a SIGHUP to the inferior. However, at this point, I don't think we care about that. |
967 ↗ | (On Diff #30001) | Nice catch. For the first problem, I propose to extend the scope of the m_stdio_communication_mutex to cover m_stdio_handle_up as well (most of the uses are covered by it already). For the second issue, I will prepare a separate change to make MainLoop thread-safe. |
source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerLLGS.cpp | ||
---|---|---|
970 ↗ | (On Diff #30166) | If eventually lldb-server will be fully single-threaded then then it's ok to keep MainLoop as-is - since anyway monitor will be part of main thread. |
1065 ↗ | (On Diff #30166) | You may wrap it up into a separate function since there are 2 usages of such code. |
source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerLLGS.cpp | ||
---|---|---|
970 ↗ | (On Diff #30166) | I have committed this with the (previously reverted) commit which removes NativeProcessLinux monitor thread. This makes lldb-server single threaded. |