[Lldb-commits] [PATCH] D121500: [lldb] Protect the debugger's output and error stream

[Jonas Devlieghere via Phabricator via lldb-commits]

JDevlieghere added a comment.

In D121500#3377434 <https://reviews.llvm.org/D121500#3377434>, @JDevlieghere wrote:

> In D121500#3377321 <https://reviews.llvm.org/D121500#3377321>, @labath wrote:
>
>> Are you sure we don't want to handle this at a higher level? The way I understand it, the main reason for the existence of PrintAsync and StreamAsynchronousIO machinery is to provide precise control about when the various bits of output get printed. That's why the asynchronous output gets plumbed through the topmost iohandler and everything. In that setup, I think the right solution would be to set up some synchronization inside/near the iohandler object.
>
> Yes, I considered doing the synchronization in the IO handler. We could have the IOHandler class hold onto a mutex. Locking it in `PrintAsync` takes care of the asynchronous output from the event thread. But everyone else is using the `File`, `StreamFile`, `FILE*` or file descriptor directly, so you need to hand out the mutex every time, in order to avoid colliding with the asynchronous output. That's certainly doable, but how long before someone forgets to lock the mutex? The benefit of doing it at a lower level is that as long as you're using the `Stream`, you're (somewhat) safe. Somewhat because you could still run into trouble when doing something that results in multiple calls to `Stream::WriteImpl`. The disadvantage is that we're still in the same boat for whoever is using the other accessors. I guess it's even slightly worse now, because there's no way to get the mutex.

https://reviews.llvm.org/D121537 shows what that would look like


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

https://reviews.llvm.org/D121500