While working on the expr completion, I've encountered the issue that sometimes lldb
deadlocks when doing input/output. The underlying cause for this is that we seem to expect
that we can always call Debugger::PrintAsync from any point of lldb and that this call will
always return at some point.
However this is not always the case. For example, when calling the completion handler, we
obviously hold locks that make the console IO thread safe. The expression parsing
code then tries to parse the user expression to provide possible completions. It's possible
that while parsing our expression, we hit a case where some code decides to print
information to the debugger output (for example to inform the user that some functionality
has failed unexpectedly). This call now deadlocks the lldb prompt as PrintAsync waits on
Editline to release the mutex, while our Editline handler waits on PrintAsync to print its error
message.
To prevent this issue in the future, this patch introduces the notion of delayed output scopes,
that essentially act as safe zones in which all calls to PrintAsync for a given debugger
are safe independently of the locking inside the IOHandlers or related issues. While printing in
this scope, we queue messages and then actually print them once we leave the scope.
Can this code become: