[Lldb-commits] [PATCH] D72748: [lldb/IOHandler] Change the way we manage IO handler

[Pavel Labath via Phabricator via lldb-commits]

labath added a comment.

Though I have messed with IOHandlers in the past, I have successfully suppressed most of the memories of it. I think I have a rough understanding of what the bug is, but I don't understand the solution yet.

With this patch, what does guarantee that the IOHandler for the `"command source -s true ./test.lldb"` thingy completes before the breakpoint callback is finished (I assume that the intention is for this to be executed synchronously)?

I don't know if this matters, but another detail to be aware of is that the IOHandler stack will be different if driving lldb through python (without calling SBDebugger::RunCommandInterpreter). In this case there won't be a stdio editline handler sitting at the bottom of the stack.



================
Comment at: lldb/source/Core/Debugger.cpp:1020
+  // they aren't running yet.
+  if (asynchronous_if_needed && !m_synchronous_reader_lock.owns_lock()) {
+    ExecuteIOHandlers();
----------------
This looks very clever, but it can still be racy if someone calls ExecuteIOHandlers concurrently to the `owns_lock` check...

A better way to achieve this (if I understand correctly what you are trying to achieve) would be to have a `ExecuteIOHandlersIfNeeded` function which does something like
```
std::unique_lock lock(m_synchronous_reader_mutex, std::try_lock);
if (lock)
  ReallyExecuteIOHandlers(); // No locking in here
```


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D72748/new/

https://reviews.llvm.org/D72748