jingham marked 5 inline comments as done. jingham added inline comments.
================ Comment at: lldb/test/API/python_api/was_interrupted/TestDebuggerInterruption.py:39 + def rendevous(self): + # We smuggle out lock and event to the runner thread using thread local data: + import interruptible ---------------- labath wrote: > This had me confused for a while, because "thread local data" has a very > specific meaning. Could you rename this to something else? I did intend to use thread local data here - that's why LockContainer derives from threading.local. The problem is that I have to use the event & lock in the Python command I will run either directly or under RunCommandInterpreter, but I don't have way to explicitly pass python objects to a command when invoking it. I could put the data in globals in the interruptible module. However, since the test variants could be running in parallel this didn't seem like a great idea. So instead I pass the test to the CommandRunner that's going to create my test thread for me, and once it's created its thread, it puts the lock & event in the thread local data, and that's where WelcomeCommand picks it up from. This is probably not 100% necessary, but seemed cleaner to me. ================ Comment at: lldb/test/API/python_api/was_interrupted/TestDebuggerInterruption.py:112 + if not "check" in args: + self.lock = threading.Lock() + self.event = threading.Event() ---------------- labath wrote: > I am confused as to what this lock's purpose is. I can see that it's taken on > one thread and released on another (which is in itself an unusual thing to > do, even though python permits it), but I still don't understand what does it > achieve. Lock are generally used for protecting a certain object. If the goal > is to control the interleaving of two threads, then maybe a sequence of > barriers would be better. Something like: > ``` > #thread 1 > work1() > t1_done.wait() > t2_done.wait() > work3() > t1_done.wait() > # etc.. odd-numbered work happens on this thread > > #thread 2 > t1_done.wait() > work2() > t2_done.wait() > t1_done.wait() > work4() > # etc.. even-numbered work happens here > ``` Here's a version using barriers exclusively. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D145136/new/ https://reviews.llvm.org/D145136 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
