[Pythonmac-SIG] Python threading.Thread vs PyObjC performOnMainThread

[Bob Ippolito]

On May 16, 2005, at 12:35 PM, gandreas at gandreas.com wrote:

> So I'm reworking how debugging is handled in PyOXIDE and I've come  
> to a problem (several, but this is the biggy for the morning).
>
> My goal is to separate interacting with the (remote) debugged  
> client in a separate thread, which forwards messages to the main  
> thread as needed to run the debugger UI (since all UI must be done  
> on the main thread).
---
> When the user says "debug", we launch the separate processes, which  
> includes a stub to open up a TCP connection back to the IDE, which  
> we use to interact with on the main event loop (which was ugly,  
> since it would then nest, well, it was ugly).  So now I call the  
> above "spawnRemoteDebugger", it talks with the targeted process,  
> and then at some point that process says "hey, let's start  
> debugging" (and transfers over a proxy object to allow the IDE to  
> interact with something that looks like a pdb object).  That's all  
> more or less fine.

I don't understand why you need to use threads from the host app.   
The best way I've found to do this is:

Host app (debugger/interpreter UI) uses async TCP interleaved with  
the main runloop (i.e. NSFileHandle, or something else)
Debugged app (application or interpreter) uses sync TCP that blocks  
waiting for interaction from the debugger

If you need a way to interrupt the debugged app asynchronously (i.e.  
ctrl-C in gdb), then set up a signal handler in the debugged app that  
installs a trace hook from the debugging bootstrap code that makes it  
go into debugging mode and send it a signal from the host app... but  
that's not something that's ever very clean in Python.

> The problem is that we then allocate and init the debugger  
> controller (PyDebuggerController).  Since that needs to be done on  
> the main thread, we use performSelectorOnMainThread.  That works  
> fine except that when this debugger controller object gets created,  
> it eventually wants to call the python code associated said  
> object.  Of course, since that's on the main thread (and not this  
> other debugger handler thread) it calls PyThread_aquire_lock.  But  
> the lock is stuck in the thread that executing the  
> performSelectorOnMainThread line, and everything just stops (the  
> main thread waits on the semaphore which will never be released).
>
> So, it appears that performSelectorOnMainThread needs some way to  
> release the lock to let Python code in the main thread be  
> executed.  Any suggestions for workarounds?

Update to PyObjC from svn and see if that makes a difference.

-bob