[Lldb-commits] [PATCH] D145136: Add a Debugger interruption mechanism in parallel to the Command Interpreter interruption

[Jim Ingham via Phabricator via lldb-commits]

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