On Tuesday 28 February 2012, 21:08:46 Lars Beiderbecke wrote:
> Hello Hans-Peter,
>
> Thanks for your answer! The connection type default
> Qt.AutoConnection should be equivalent to Qt.QueuedConnection, which
> in turn should be the right kind of connection to avoid race
> conditions. With both types, however, I do experience a race
> condition.
Correct.
> With type Qt.DirectConnection on the other hand I get a
> runtime error
>
> TypeError: ack() takes exactly 2 arguments (1 given)
>
> that I don't understand at the moment.
>
> I've attached a self-contained program that can be run to show the
> race condition (just configure the path to some large(!) image file).
> The output of the program is:
>
> ~ > ./racecond.py
> START: image.jpg
> RUN: image.jpg
> WARNING: thread not finished: image.jpg
> ACK: image.jpg
>
> Again, why is the WARNING printed if run() has completed execution?
> To quote from the documentation for QueuedConnection: "The slot is
> invoked when control returns to the event loop of the receiver's
> thread." That should give run() plenty of time to finish after
> emitting the signal, no?
No, signals do not serialize in that way, they only make sure to run in
the right context.
What you seem to be after is:
connect the finished signal in your ImgRequest class to a helper method,
from where you emit sigDone. Now, your signals are serialized with the
finished threads.
Again, new style signals trump, just derive your emitting classes from a
QObject descendant (QThread is), define your own signal with:
sigDone = QtCore.pyqtSignal(QtCore.QThread)
and emit with
self.sigDone.emit(self)
Pete
_______________________________________________
PyQt mailing list PyQt@riverbankcomputing.com
http://www.riverbankcomputing.com/mailman/listinfo/pyqt
