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
_______________________________________________
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
