On Friday 23 February 2007 14:34, Matt Newell wrote: > On Friday 23 February 2007 12:52, Matt Newell wrote: > > On Friday 23 February 2007 12:38, Michael Guntsche wrote: > > > On Feb 23, 2007, at 20:43, Matt Newell wrote: > > > > ... > > > > > Hello Matt, > > > > > > Can you try and change the connect to a QueuedConnection? It looks > > > like it is using a "DirectConnection" now. > > > I was sure I tried that before, but back then I was using events and > > > not signals. > > > > It's already (correctly) using a queued connection to send the signal. > > I've already tracked it down further and eliminated one of the deadlock > > code paths by putting a /ReleaseGIL/ annotation on QLabel::setText. > > There is another deadlock though happening in the connect call which i'm > > tracking down now. > > > > > I tried it on my computer, but although the "connect" returns True I > > > do not get the emitted signal in my main thread. > > > I do not understand why. > > > > Hmm, i'm not sure why that would happen. > > So here's the deal. In order to avoid deadlocks we must avoid running any > Qt code that will require a lock while the GIL is locked. This is because > we can't avoid the opposite, which is acquiring the GIL while Qt is holding > a lock( For example Qt holds a lock while copying signal data for queued > connections, and we have to run python code for that. ) To avoid a > deadlock we must avoid one or the other. > > This means that any Qt calls that do a connect, or create/destroy any > qobjects must first release the GIL. There may be other code paths in Qt > that require the same care. > > Try testing with this patch, it eliminates all deadlocks for me. > I still get deadlocks when destroying the threads unless I add /ReleaseGIL/ to the QThread dtor.
I think that right now there are many potential deadlocks in PyQt. All QObject and derived classes need their ctors and dtors marked /ReleaseGIL/. All connect/disconnect functions, any functions that indirectly delete or create qobjects, etc. Essentially the entire api needs to be reviewed. Matt _______________________________________________ PyKDE mailing list [email protected] http://mats.imk.fraunhofer.de/mailman/listinfo/pykde
