[Lldb-commits] [PATCH] D127922: [lldb] Introduce the concept of a log handler (NFC)
Greg Clayton via Phabricator via lldb-commits
lldb-commits at lists.llvm.org
Thu Jun 16 11:23:32 PDT 2022
clayborg added inline comments.
================
Comment at: lldb/include/lldb/Utility/Log.h:54
+ virtual void Flush() = 0;
+ std::mutex &GetMutex() { return m_mutex; }
+
----------------
Maybe we don't expose this mutex at all and we have a EmitThreadSafe(...) method?:
```
void EmitThreadSafe(llvm::StringRef message) {
std::lock_guard<std::mutex> guard(m_mutex);
Emit(message);
}
```
================
Comment at: lldb/source/Utility/Log.cpp:323-324
if (options.Test(LLDB_LOG_OPTION_THREADSAFE)) {
- static std::recursive_mutex g_LogThreadedMutex;
- std::lock_guard<std::recursive_mutex> guard(g_LogThreadedMutex);
- *stream_sp << message;
- stream_sp->flush();
+ std::lock_guard<std::mutex> guard(handler_sp->GetMutex());
+ handler_sp->Emit(message);
+ handler_sp->Flush();
----------------
If we like the idea of EmitThreadSafe then the code can look like this
================
Comment at: lldb/source/Utility/Log.cpp:325
+ handler_sp->Emit(message);
+ handler_sp->Flush();
} else {
----------------
Do we ever not call Flush() after a Emit() call? If so do we even need the flush call, or should we just leave it up to the specific implementation to do what it wants in Emit(...)?
================
Comment at: lldb/source/Utility/Log.cpp:328
+ handler_sp->Emit(message);
+ handler_sp->Flush();
}
----------------
Do we ever not call Flush() after a Emit() call? If so do we even need the flush call, or should we just leave it up to the specific implementation to do what it wants in Emit(...)?
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D127922/new/
https://reviews.llvm.org/D127922
More information about the lldb-commits
mailing list