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