PyQt in-depth: типы signal-slot соединений

В Qt слоты и сигналы являются платформенно-независимым средством обмена сообщениями между объектами. Подробнее писать о них я не собираюсь, так это хорошо сделали до меня прямо в документации Qt или, например, вот здесь. Я хочу выделить некоторые особенности их использования, с которыми мне удалось столкнуться.

Signal-slot механизм - это не просто вызов колбеков в чистом виде. Между сигналом и слотом устанавливается соединение, которое может быть 4-х типов:

• DirectConnection - прямое соединение, когда сигнал моментально обрабатывается слотом;
  
  
• QueuedConnection - сигнал добавляется в очередь и ожидает своего "выхода" в очереди сообщений, при этом поток, в котором возник сигнал не блокируется;
  
  
• BlockingQueuedConnection - то же, что и QueuedConnection, но вызывающий поток блокируется, пока сигнал не будет обработан;
  
  
• AutoConnection - автоматически выбирается DirectConnection, если сигнал вызывается из того же потока, в котором живет приемник, и QueuedConnection, если используются разные потоки.

Как видно, два соединения являются синхронными, одно асинхронным и одно автоматически выбирает себе соответствующий тип в зависимости от внешнего окружения.

Тип соединения указывается как параметр QObject.connect:

QObject.connect(doer, SIGNAL('event'), self.handle, Qt.DirectConnection)

Теперь, как это все работает на примере. Пусть есть задача, которую надо выполнить в отдельном потоке (класс Doer) и обработчик, который должен узнать о результате выполнения (класс Handler).
<br />from PyQt4 import QtGui, QtCore<br />import sys<br /># пользуется стандартная питоновкая либа для работы с потоками, а не <br /># Qt-шная, так как у первой красивше информации о текущем потоке<br />import threading<br /><br />class Doer(QtCore.QObject):<br /><br /> def __init__(self):<br /> QtCore.QObject.__init__(self)<br /> self.thread = threading.Thread(target=self.run) <br /><br /> def start(self):<br /> self.thread.start()<br /><br /> def run(self):<br /> print 'task in thread', threading.currentThread() <br /> self.emit(QtCore.SIGNAL('event'))<br /> print 'after notify'<br /><br />class Handler(QtCore.QObject):<br /><br /> def __init__(self, doer, ctype):<br /> QtCore.QObject.__init__(self)<br /> QtCore.QObject.connect(doer, QtCore.SIGNAL('event'), self.handleNotify, ctype)<br /><br /> def handleNotify(self):<br /> print 'handle in thread', threading.currentThread()<br /> import time<br /> time.sleep(2) <br /> print 'handle finish'<br /><br />app = QtGui.QApplication(sys.argv)<br /><br />d = Doer()<br />handler = Handler(d, QtCore.Qt.DirectConnection)<br />d.start() <br /><br />sys.exit(app.exec_()) <br />
На это примере можно проследить где и когда будет отрабатываться слот в зависимости типа соединения.

В случае DirectConnection, сигнал обрабатывается синхронно, в потоке, где выполнялась задача:

task in thread < Thread(Thread-1, started) >
handle in thread < Thread(Thread-1, started) >
handle finish
after notify

При QueuedConnection, сигнал обрабатывается асинхронно в главном потоке приложения:

task in thread < Thread(Thread-1, started) >
after notify
handle in thread < _MainThread(MainThread, started) >
handle finish

BlockingQueuedConnection заставляет поток, вызывающий сигнал, ждать обработки, которая происходит в главном потоке приложения:

task in thread < Thread(Thread-1, started) >
handle in thread < _MainThread(MainThread, started) >
handle finish
after notify

При AutoConnection ситуация такая же как и при QueuedConnection, так как сигнал и приемник в разных потоках:

task in thread < Thread(Thread-1, started) >
after notify
handle in thread <_MainThread(MainThread, started)>
handle finish

Но если изменить одну строчку кода результат будет таким же как при DirectConnection:
<br />#d.start()<br /># теперь Doer.run будет выполняться в основном потоке<br />d.run()<br />
task in thread <_MainThread(MainThread, started)>
handle in thread <_MainThread(MainThread, started)>
handle finish
after notify

Тип соединения BlockingQueuedConnection стоит использовать только в многопоточных приложениях, так как в одном потоке может привести к dead lock'у, о чем Qt должно предупредить ворнингом:

Qt: Dead lock detected while activating a BlockingQueuedConnection

Таким образом, Qt позволяет гибко настраивать обработку сигналов в синхронном и асинхронном режиме, в одном или нескольких потоках.