labath added inline comments.

================
Comment at: lldb/source/Plugins/Process/Linux/NativeProcessLinux.cpp:1909
+             wait_status);
+    tid_events.try_emplace(thread_up->GetID(), wait_status);
+  }
----------------
mgorny wrote:
> Hmm, I'm a bit confused here. Why would the key already exist? I mean, you 
> start with empty `tid_events` and catch only one event for every thread, 
> correct?
It doesn't exist. It's just how the api is named. c++ std::map offers both 
emplace and try_emplace (which, ironically, don't differ in "trying" -- they 
only differ in the way they construct the pair). DenseMap offers only 
try_emplace (maybe for that reason).


================
Comment at: lldb/source/Plugins/Process/Linux/NativeProcessLinux.cpp:1918
+    } else {
+      // This can happen if one of the events is an main thread exit.
+      LLDB_LOG(log, "... but the thread has disappeared");
----------------
mgorny wrote:
> Are we talking about some kind of race here? Or some thread that appears in 
> `m_threads` but is not returned by `GetThreadByID()`?
> 
> I was wondering if you could use thread pointers as keys.
The problem is when a thread disappears. This can happen in case of a main 
thread exit or an execve, in which case we remove all non-main threads from the 
list. However, we can still have some pending events for the other threads. 
Now, I haven't managed to reproduce this in my experiments, but the manpage is 
adamant that a SIGKILL should immediately terminate a process. In my (limited) 
tests the debugger always got a PTRACE_EVENT_EXIT stop for each threads (which 
is again something that the manpage says should not happen), so we 
theoretically (with careful management of thread lifetimes) might ensure that a 
thread with pending events does not disappear, but depending on it doesn't seem 
like a good idea.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D116372

_______________________________________________
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

Reply via email to