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?
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. On Tue, Mar 10, 2009 at 2:30 PM, McKay Davis <[email protected]> wrote: > After no response, maybe more specifics with our Multi-Threaded Python > w/ PyQt problem would help: > > In the main thread, we do: > > PyEval_InitThreads(); // acquires the lock > PyInitialize(); > // other init stuff > PyThread_release_lock() > > …and in each new Python thread we do: > Py_NewInterpreter() > … > PyThreads_release_lock() > > We call release()/acquire() blocks whenever the python script does a > blocking operation. A specific example of a lockup with PyQT is > running examples/tutorial/t8.pyw. We basically: > > PyThreads_acquire_lock() > <run example script> > PyThreads_release_lock() > > When a slot is invoked as a result of the slider being moved we get a > deadlock. This happens when sip_ProtectVirt_languageChange calls > PyThreads_release_lock() on an already released lock. If we don’t > release the lock after the main thread PyQT script code runs, then the > script runs fine – but our other python script threads will be starved > out. > > Anybody have any ideas on how to resolve this deadlock? > > -McKay Davis > - Show quoted text - > > On Mon, Mar 9, 2009 at 2:12 PM, McKay Davis <[email protected]> wrote: > > > > All, > > > > 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. > > > > 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. > > > > 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. > > > > Thanks, > > > > McKay Davis > > _______________________________________________ > PyQt mailing list [email protected] > http://www.riverbankcomputing.com/mailman/listinfo/pyqt >
_______________________________________________ PyQt mailing list [email protected] http://www.riverbankcomputing.com/mailman/listinfo/pyqt
