[PyQt] Re: Embedding w/ multi-threaded Python

[Marc Nations]

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
> 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 <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
> http://www.riverbankcomputing.com/mailman/listinfo/pyqt
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.riverbankcomputing.com/pipermail/pyqt/attachments/20090310/6c509b51/attachment.html