COM automation and threading in python

[TecHNooB]

The question is kind of specific, but is there any reason my UI (made using PyQT) locks up when running COM automation on a separate thread? Also, if you have multiple threads and you break in debug, shouldn't all threads stop? Cuz mine keep going:|

 

[Markbnj]

I'm not sure on the automation question. It's been too long. On the debugger question, the normal behavior is that the thread that hits the breakpoint breaks, but other threads continue to run. To get more control and isolate activity you can bring up the threads window and freeze/thaw threads individually or as a group, switch to another thread's call stack, and do other neat and useful things.

 

[Cogman]

I'm not sure on the automation question. It's been too long. On the debugger question, the normal behavior is that the thread that hits the breakpoint breaks, but other threads continue to run. To get more control and isolate activity you can bring up the threads window and freeze/thaw threads individually or as a group, switch to another thread's call stack, and do other neat and useful things.

Which is why debugging threaded programs is somewhat of a pain.

For the COM question, Does the COM operation change, in ANY way the way the window looks? If so, this is a limitation of windows. Only the thread which creates the window is allowed to draw to that window. As a result, QT or the COM module is somehow scheduling its action with the main thread's message pump.

There might also be a limitation on which thread is allowed to access a dll (I'm not sure on this one).

 

[TecHNooB]

Which is why debugging threaded programs is somewhat of a pain.

For the COM question, Does the COM operation change, in ANY way the way the window looks? If so, this is a limitation of windows. Only the thread which creates the window is allowed to draw to that window. As a result, QT or the COM module is somehow scheduling its action with the main thread's message pump.

There might also be a limitation on which thread is allowed to access a dll (I'm not sure on this one).

Nope :|

 

[Cogman]

Nope :|

My bet, then, is that PyQT is helpfully making that process single threaded for you. The authors probably figured there would be a lot less errors (as COM objects are not always thread safe) if they simply forced all COM interactions to occur from the main thread. (that, or they have implemented their own blocking stuff which makes it appear like things are running single threadedly)

 

[Venix]

I don't know Python, but it sounds like the COM object is running in the same single-threaded apartment as the main thread. In other languages this same behavior would occur if the COM object were created in the main thread and then accessed from a second thread. The solution would be to create the object in a different thread.

 

[TecHNooB]

I don't know Python, but it sounds like the COM object is running in the same single-threaded apartment as the main thread. In other languages this same behavior would occur if the COM object were created in the main thread and then accessed from a second thread. The solution would be to create the object in a different thread.

Well what I do is I create a new thread then call something like ..

app = DispatchEx('ApplicationName', hostname);

on the new thread. Maybe there is something inherently wrong with this :| I'll check with one of our COM guys :|