[PyQt] Re: Embedding w/ multi-threaded Python
mnations.lists at gmail.com
Tue Mar 10 20:45:21 GMT 2009
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 <mckay.cpp at gmail.com> 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
> // other init stuff
> …and in each new Python thread we do:
> 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:
> <run example script>
> 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
> 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 <mckay.cpp at gmail.com> 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 PyQt at riverbankcomputing.com
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the PyQt