Are you putting a small sleep (100 msec) in all your continuous thread loops to ensure that control gets passed back to the main thread? <br><br><div>Sounds like a minor issue, but it can be a silent killer. Even with locks Python doesn't automatically handle the handoffs well. I don't think that changed with the multiprocessing features introduced in 2.6 either, but I haven't read much about it.</div>
<div><div><br></div><div><br></div><div><br><div class="gmail_quote">On Tue, Mar 10, 2009 at 2:30 PM, McKay Davis <span dir="ltr"><<a href="mailto:mckay.cpp@gmail.com">mckay.cpp@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
After no response, maybe more specifics with our Multi-Threaded Python<br>
w/ PyQt problem would help:<br>
<br>
In the main thread, we do:<br>
<br>
PyEval_InitThreads(); // acquires the lock<br>
PyInitialize();<br>
// other init stuff<br>
PyThread_release_lock()<br>
<br>
…and in each new Python thread we do:<br>
Py_NewInterpreter()<br>
…<br>
PyThreads_release_lock()<br>
<br>
We call release()/acquire() blocks whenever the python script does a<br>
blocking operation. A specific example of a lockup with PyQT is<br>
running examples/tutorial/t8.pyw. We basically:<br>
<br>
PyThreads_acquire_lock()<br>
<run example script><br>
PyThreads_release_lock()<br>
<br>
When a slot is invoked as a result of the slider being moved we get a<br>
deadlock. This happens when sip_ProtectVirt_languageChange calls<br>
PyThreads_release_lock() on an already released lock. If we don’t<br>
release the lock after the main thread PyQT script code runs, then the<br>
script runs fine – but our other python script threads will be starved<br>
out.<br>
<br>
Anybody have any ideas on how to resolve this deadlock?<br>
<br>
-McKay Davis<br>
<div><div><span id="q_11ff2297bf53f707_1" class="h4">- Show quoted text -</span></div><div class="h5"><br>
On Mon, Mar 9, 2009 at 2:12 PM, McKay Davis <<a href="mailto:mckay.cpp@gmail.com">mckay.cpp@gmail.com</a>> wrote:<br>
><br>
> All,<br>
><br>
> We are encountering difficulties embedding PyQT into our application. In our situation, we provide the capability to run multiple python interpreters simultaneously along with the main thread PyQT interpreter.<br>
><br>
> We try to correctly manage the python global interpreter lock in such a way so that we can run PyQT python code in conjunction with non-PyQt python code running in other threads. What we have found however, is that under some circumstances (ie , our application will deadlock since there appears to be an implicit assumption that the global interpreter lock is already held the moment that slot code is invoked by PyQT.<br>
><br>
> We can assure this to be the case, but only at the expense of locking other python code threads out of the global interpreter lock. Are there any provisions to accommodate what we are trying to do that we are not making use of? Or is this perhaps a known issue? Are there any workarounds? We would appreciate any help or tips on this.<br>
><br>
> Thanks,<br>
><br>
> McKay Davis<br>
<br>
</div></div>_______________________________________________<br>
PyQt mailing list <a href="mailto:PyQt@riverbankcomputing.com">PyQt@riverbankcomputing.com</a><br>
<a href="http://www.riverbankcomputing.com/mailman/listinfo/pyqt" target="_blank">http://www.riverbankcomputing.com/mailman/listinfo/pyqt</a><br>
</blockquote></div><br></div></div>