https://github.com/labath commented:
So, the problem I see here is that this is enforcing mutual exclusion at the level of most basic write operations. That's fine if what you want to achieve is to protect the internal state of the stream object. However, I'm not sure if that's your goal, since it doesn't e.g. prevent someone from printing something in the middle of a statusline update. It also may be unnecessary since I believe that both file descriptors and FILE* objects are synchronized internally (one by the OS, the other by the C library). To achieve proper output synchronization, the exclusion needs to happen at a higher level (e.g. "a single statusline update", or "writing of one line of text", etc.). In theory, that can be done using the provided `GetMutex` accessor, but it's also very easy to forget doing that. To better guarantee that, I am wondering if a slightly different pattern wouldn't be better. We could have one object (let's call it LockableStream here, just so it differs from what you have in this PR), which holds the real stream (and a mutex) as a *member*, and doesn't allow you to access it without locking it. Then, when you want write something, you call a `Lock` function or something (it could also be constructing a guard object and passing the LockableStream to its constructor), and this returns something that allows you to access the underlying stream. As long as you hold on to the returned object (which contains a lock_guard on the stream mutex internally), you are permitted to write to the stream. The destruction of the object can automatically flush the output stream. WDYT? https://github.com/llvm/llvm-project/pull/126630 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
