Hilo de fondo con QThread en PyQt

Tengo un progtwig que interactúa con una radio que estoy usando a través de un gui que escribí en PyQt. Obviamente, una de las funciones principales de la radio es transmitir datos, pero para hacer esto continuamente, tengo que hacer un bucle de las escrituras, lo que hace que la interfaz gráfica de usuario cuelgue. Como nunca he tratado con el subprocesamiento, intenté deshacerme de estos lockings usando QCoreApplication.processEvents(). Sin embargo, la radio necesita dormir entre las transmisiones, por lo que la interfaz gráfica de usuario aún se cuelga en función de cuánto duran estos últimos.

¿Hay una manera simple de arreglar esto usando QThread? He buscado tutoriales sobre cómo implementar subprocesos múltiples con PyQt, pero la mayoría de ellos se ocupan de configurar servidores y son mucho más avanzados de lo que necesito que sean. Sinceramente, ni siquiera necesito realmente mi hilo para actualizar nada mientras se está ejecutando, solo necesito iniciarlo, transmitirlo en segundo plano y detenerlo.

Creé un pequeño ejemplo que muestra 3 formas diferentes y simples de tratar con hilos. Espero que te ayude a encontrar el enfoque correcto para tu problema.

 import sys import time from PyQt5.QtCore import (QCoreApplication, QObject, QRunnable, QThread, QThreadPool, pyqtSignal) # Subclassing QThread # http://qt-project.org/doc/latest/qthread.html class AThread(QThread): def run(self): count = 0 while count < 5: time.sleep(1) print("A Increasing") count += 1 # Subclassing QObject and using moveToThread # http://blog.qt.digia.com/blog/2007/07/05/qthreads-no-longer-abstract class SomeObject(QObject): finished = pyqtSignal() def long_running(self): count = 0 while count < 5: time.sleep(1) print("B Increasing") count += 1 self.finished.emit() # Using a QRunnable # http://qt-project.org/doc/latest/qthreadpool.html # Note that a QRunnable isn't a subclass of QObject and therefore does # not provide signals and slots. class Runnable(QRunnable): def run(self): count = 0 app = QCoreApplication.instance() while count < 5: print("C Increasing") time.sleep(1) count += 1 app.quit() def using_q_thread(): app = QCoreApplication([]) thread = AThread() thread.finished.connect(app.exit) thread.start() sys.exit(app.exec_()) def using_move_to_thread(): app = QCoreApplication([]) objThread = QThread() obj = SomeObject() obj.moveToThread(objThread) obj.finished.connect(objThread.quit) objThread.started.connect(obj.long_running) objThread.finished.connect(app.exit) objThread.start() sys.exit(app.exec_()) def using_q_runnable(): app = QCoreApplication([]) runnable = Runnable() QThreadPool.globalInstance().start(runnable) sys.exit(app.exec_()) if __name__ == "__main__": #using_q_thread() #using_move_to_thread() using_q_runnable() 

Tome esta respuesta actualizada para PyQt5, python 3.4

Use esto como un patrón para iniciar a un trabajador que no toma datos y devuelva datos cuando estén disponibles para el formulario.

1 – La clase Worker se hace más pequeña y se coloca en su propio archivo worker.py para una fácil memorización y reutilización independiente del software.

2 – El archivo main.py es el archivo que define la clase de formulario GUI

3 – El objeto hilo no está subclasificado.

4 – Tanto el objeto de hilo como el objeto de trabajo pertenecen al objeto de formulario

5 – Los pasos del procedimiento están dentro de los comentarios.

 # worker.py from PyQt5.QtCore import QThread, QObject, pyqtSignal, pyqtSlot import time class Worker(QObject): finished = pyqtSignal() intReady = pyqtSignal(int) @pyqtSlot() def procCounter(self): # A slot takes no params for i in range(1, 100): time.sleep(1) self.intReady.emit(i) self.finished.emit() 

Y el archivo principal es:

  # main.py from PyQt5.QtCore import QThread from PyQt5.QtWidgets import QApplication, QLabel, QWidget, QGridLayout import sys import worker class Form(QWidget): def __init__(self): super().__init__() self.label = QLabel("0") # 1 - create Worker and Thread inside the Form self.obj = worker.Worker() # no parent! self.thread = QThread() # no parent! # 2 - Connect Worker`s Signals to Form method slots to post data. self.obj.intReady.connect(self.onIntReady) # 3 - Move the Worker object to the Thread object self.obj.moveToThread(self.thread) # 4 - Connect Worker Signals to the Thread slots self.obj.finished.connect(self.thread.quit) # 5 - Connect Thread started signal to Worker operational slot method self.thread.started.connect(self.obj.procCounter) # * - Thread finished signal will close the app if you want! #self.thread.finished.connect(app.exit) # 6 - Start the thread self.thread.start() # 7 - Start the form self.initUI() def initUI(self): grid = QGridLayout() self.setLayout(grid) grid.addWidget(self.label,0,0) self.move(300, 150) self.setWindowTitle('thread test') self.show() def onIntReady(self, i): self.label.setText("{}".format(i)) #print(i) app = QApplication(sys.argv) form = Form() sys.exit(app.exec_()) 

Muy buen ejemplo de Matt, arreglé el error tipográfico y también pyqt4.8 es común ahora, así que también eliminé la clase ficticia y agregué un ejemplo para la señal dataReady

 # -*- coding: utf-8 -*- import sys from PyQt4 import QtCore, QtGui from PyQt4.QtCore import Qt # very testable class (hint: you can use mock.Mock for the signals) class Worker(QtCore.QObject): finished = QtCore.pyqtSignal() dataReady = QtCore.pyqtSignal(list, dict) @QtCore.pyqtSlot() def processA(self): print "Worker.processA()" self.finished.emit() @QtCore.pyqtSlot(str, list, list) def processB(self, foo, bar=None, baz=None): print "Worker.processB()" for thing in bar: # lots of processing... self.dataReady.emit(['dummy', 'data'], {'dummy': ['data']}) self.finished.emit() def onDataReady(aList, aDict): print 'onDataReady' print repr(aList) print repr(aDict) app = QtGui.QApplication(sys.argv) thread = QtCore.QThread() # no parent! obj = Worker() # no parent! obj.dataReady.connect(onDataReady) obj.moveToThread(thread) # if you want the thread to stop after the worker is done # you can always call thread.start() again later obj.finished.connect(thread.quit) # one way to do it is to start processing as soon as the thread starts # this is okay in some cases... but makes it harder to send data to # the worker object from the main gui thread. As you can see I'm calling # processA() which takes no arguments thread.started.connect(obj.processA) thread.finished.connect(app.exit) thread.start() # another way to do it, which is a bit fancier, allows you to talk back and # forth with the object in a thread safe way by communicating through signals # and slots (now that the thread is running I can start calling methods on # the worker object) QtCore.QMetaObject.invokeMethod(obj, 'processB', Qt.QueuedConnection, QtCore.Q_ARG(str, "Hello World!"), QtCore.Q_ARG(list, ["args", 0, 1]), QtCore.Q_ARG(list, [])) # that looks a bit scary, but its a totally ok thing to do in Qt, # we're simply using the system that Signals and Slots are built on top of, # the QMetaObject, to make it act like we safely emitted a signal for # the worker thread to pick up when its event loop resumes (so if its doing # a bunch of work you can call this method 10 times and it will just queue # up the calls. Note: PyQt > 4.6 will not allow you to pass in a None # instead of an empty list, it has stricter type checking app.exec_() 

Según los desarrolladores de Qt, la subclasificación de QThread es incorrecta (consulte http://blog.qt.io/blog/2010/06/17/youre-doing-it-wrong/ ). Pero ese artículo es realmente difícil de entender (además el título es un poco condescendiente). Encontré una mejor publicación en el blog que brinda una explicación más detallada sobre por qué debería usar un estilo de subprocesos en lugar de otro: http://mayaposch.wordpress.com/2011/11/01/how-to-really-truly-use- qthreads-the-full-explicación /

En mi opinión, probablemente nunca deberías sub-crear subprocesos con la intención de sobrecargar el método de ejecución. Si bien eso funciona, básicamente estás eludiendo cómo Qt quiere que trabajes. Además, se perderá de cosas como eventos y señales y ranuras seguras para subprocesos. Además, como es probable que veas en la publicación del blog anterior, la forma “correcta” de enlazar te obliga a escribir más códigos comprobables.

Aquí hay un par de ejemplos de cómo aprovechar QThreads en PyQt (publiqué una respuesta por separado a continuación que utiliza QRunnable e incorpora señales / slots, esa respuesta es mejor si tiene muchas tareas asíncronas que necesita para equilibrar la carga) .

 import sys from PyQt4 import QtCore from PyQt4 import QtGui from PyQt4.QtCore import Qt # very testable class (hint: you can use mock.Mock for the signals) class Worker(QtCore.QObject): finished = QtCore.pyqtSignal() dataReady = QtCore.pyqtSignal(list, dict) @QtCore.pyqtSlot() def processA(self): print "Worker.processA()" self.finished.emit() @QtCore.pyqtSlot(str, list, list) def processB(self, foo, bar=None, baz=None): print "Worker.processB()" for thing in bar: # lots of processing... self.dataReady.emit(['dummy', 'data'], {'dummy': ['data']}) self.finished.emit() class Thread(QtCore.QThread): """Need for PyQt4 <= 4.6 only""" def __init__(self, parent=None): QtCore.QThread.__init__(self, parent) # this class is solely needed for these two methods, there # appears to be a bug in PyQt 4.6 that requires you to # explicitly call run and start from the subclass in order # to get the thread to actually start an event loop def start(self): QtCore.QThread.start(self) def run(self): QtCore.QThread.run(self) app = QtGui.QApplication(sys.argv) thread = Thread() # no parent! obj = Worker() # no parent! obj.moveToThread(thread) # if you want the thread to stop after the worker is done # you can always call thread.start() again later obj.finished.connect(thread.quit) # one way to do it is to start processing as soon as the thread starts # this is okay in some cases... but makes it harder to send data to # the worker object from the main gui thread. As you can see I'm calling # processA() which takes no arguments thread.started.connect(obj.processA) thread.start() # another way to do it, which is a bit fancier, allows you to talk back and # forth with the object in a thread safe way by communicating through signals # and slots (now that the thread is running I can start calling methods on # the worker object) QtCore.QMetaObject.invokeMethod(obj, 'processB', Qt.QueuedConnection, QtCore.Q_ARG(str, "Hello World!"), QtCore.Q_ARG(list, ["args", 0, 1]), QtCore.Q_ARG(list, [])) # that looks a bit scary, but its a totally ok thing to do in Qt, # we're simply using the system that Signals and Slots are built on top of, # the QMetaObject, to make it act like we safely emitted a signal for # the worker thread to pick up when its event loop resumes (so if its doing # a bunch of work you can call this method 10 times and it will just queue # up the calls. Note: PyQt > 4.6 will not allow you to pass in a None # instead of an empty list, it has stricter type checking app.exec_() # Without this you may get weird QThread messages in the shell on exit app.deleteLater() 

En PyQt hay muchas opciones para obtener un comportamiento asíncrono. Para las cosas que necesitan procesamiento de eventos (es decir, QtNetwork, etc.), debe usar el ejemplo QThread que proporcioné en mi otra respuesta en este hilo. Pero para la gran mayoría de sus necesidades de subprocesamiento, creo que esta solución es muy superior a los otros métodos.

La ventaja de esto es que QThreadPool progtwig sus instancias de QRunnable como tareas. Esto es similar al patrón de tarea utilizado en TBB de Intel. No es tan elegante como me gusta, pero logra un excelente comportamiento asíncrono.

Esto le permite utilizar la mayor parte del poder de subprocesamiento de Qt en Python a través de QRunnable y aprovechar las señales y las ranuras. Uso este mismo código en varias aplicaciones, algunas que hacen cientos de llamadas REST asíncronas, otras que abren archivos o listan directorios, y la mejor parte es usar este método, la tarea Qt equilibra los recursos del sistema para mí.

 import time from PyQt4 import QtCore from PyQt4 import QtGui from PyQt4.QtCore import Qt def async(method, args, uid, readycb, errorcb=None): """ Asynchronously runs a task :param func method: the method to run in a thread :param object uid: a unique identifier for this task (used for verification) :param slot updatecb: the callback when data is receieved cb(uid, data) :param slot errorcb: the callback when there is an error cb(uid, errmsg) The uid option is useful when the calling code makes multiple async calls and the callbacks need some context about what was sent to the async method. For example, if you use this method to thread a long running database call and the user decides they want to cancel it and start a different one, the first one may complete before you have a chance to cancel the task. In that case, the "readycb" will be called with the cancelled task's data. The uid can be used to differentiate those two calls (ie. using the sql query). :returns: Request instance """ request = Request(method, args, uid, readycb, errorcb) QtCore.QThreadPool.globalInstance().start(request) return request class Request(QtCore.QRunnable): """ A Qt object that represents an asynchronous task :param func method: the method to call :param list args: list of arguments to pass to method :param object uid: a unique identifier (used for verification) :param slot readycb: the callback used when data is receieved :param slot errorcb: the callback used when there is an error The uid param is sent to your error and update callbacks as the first argument. It's there to verify the data you're returning After created it should be used by invoking: .. code-block:: python task = Request(...) QtCore.QThreadPool.globalInstance().start(task) """ INSTANCES = [] FINISHED = [] def __init__(self, method, args, uid, readycb, errorcb=None): super(Request, self).__init__() self.setAutoDelete(True) self.cancelled = False self.method = method self.args = args self.uid = uid self.dataReady = readycb self.dataError = errorcb Request.INSTANCES.append(self) # release all of the finished tasks Request.FINISHED = [] def run(self): """ Method automatically called by Qt when the runnable is ready to run. This will run in a separate thread. """ # this allows us to "cancel" queued tasks if needed, should be done # on shutdown to prevent the app from hanging if self.cancelled: self.cleanup() return # runs in a separate thread, for proper async signal/slot behavior # the object that emits the signals must be created in this thread. # Its not possible to run grabber.moveToThread(QThread.currentThread()) # so to get this QObject to properly exhibit asynchronous # signal and slot behavior it needs to live in the thread that # we're running in, creating the object from within this thread # is an easy way to do that. grabber = Requester() grabber.Loaded.connect(self.dataReady, Qt.QueuedConnection) if self.dataError is not None: grabber.Error.connect(self.dataError, Qt.QueuedConnection) try: result = self.method(*self.args) if self.cancelled: # cleanup happens in 'finally' statement return grabber.Loaded.emit(self.uid, result) except Exception as error: if self.cancelled: # cleanup happens in 'finally' statement return grabber.Error.emit(self.uid, unicode(error)) finally: # this will run even if one of the above return statements # is executed inside of the try/except statement see: # https://docs.python.org/2.7/tutorial/errors.html#defining-clean-up-actions self.cleanup(grabber) def cleanup(self, grabber=None): # remove references to any object or method for proper ref counting self.method = None self.args = None self.uid = None self.dataReady = None self.dataError = None if grabber is not None: grabber.deleteLater() # make sure this python obj gets cleaned up self.remove() def remove(self): try: Request.INSTANCES.remove(self) # when the next request is created, it will clean this one up # this will help us avoid this object being cleaned up # when it's still being used Request.FINISHED.append(self) except ValueError: # there might be a race condition on shutdown, when shutdown() # is called while the thread is still running and the instance # has already been removed from the list return @staticmethod def shutdown(): for inst in Request.INSTANCES: inst.cancelled = True Request.INSTANCES = [] Request.FINISHED = [] class Requester(QtCore.QObject): """ A simple object designed to be used in a separate thread to allow for asynchronous data fetching """ # # Signals # Error = QtCore.pyqtSignal(object, unicode) """ Emitted if the fetch fails for any reason :param unicode uid: an id to identify this request :param unicode error: the error message """ Loaded = QtCore.pyqtSignal(object, object) """ Emitted whenever data comes back successfully :param unicode uid: an id to identify this request :param list data: the json list returned from the GET """ NetworkConnectionError = QtCore.pyqtSignal(unicode) """ Emitted when the task fails due to a network connection error :param unicode message: network connection error message """ def __init__(self, parent=None): super(Requester, self).__init__(parent) class ExampleObject(QtCore.QObject): def __init__(self, parent=None): super(ExampleObject, self).__init__(parent) self.uid = 0 self.request = None def ready_callback(self, uid, result): if uid != self.uid: return print "Data ready from %s: %s" % (uid, result) def error_callback(self, uid, error): if uid != self.uid: return print "Data error from %s: %s" % (uid, error) def fetch(self): if self.request is not None: # cancel any pending requests self.request.cancelled = True self.request = None self.uid += 1 self.request = async(slow_method, ["arg1", "arg2"], self.uid, self.ready_callback, self.error_callback) def slow_method(arg1, arg2): print "Starting slow method" time.sleep(1) return arg1 + arg2 if __name__ == "__main__": import sys app = QtGui.QApplication(sys.argv) obj = ExampleObject() dialog = QtGui.QDialog() layout = QtGui.QVBoxLayout(dialog) button = QtGui.QPushButton("Generate", dialog) progress = QtGui.QProgressBar(dialog) progress.setRange(0, 0) layout.addWidget(button) layout.addWidget(progress) button.clicked.connect(obj.fetch) dialog.show() app.exec_() app.deleteLater() # avoids some QThread messages in the shell on exit # cancel all running tasks avoid QThread/QTimer error messages # on exit Request.shutdown() 

Cuando salga de la aplicación, querrá asegurarse de cancelar todas las tareas o la aplicación se bloqueará hasta que todas las tareas progtwigdas se hayan completado.

Basándome en los métodos de los objetos del Trabajador mencionados en otras respuestas, decidí ver si podía ampliar la solución para invocar más subprocesos: en este caso, el número óptimo que la máquina puede ejecutar y hacer girar múltiples trabajadores con tiempos de finalización indeterminados. Para hacer esto, todavía necesito subclasificar QThread, pero solo para asignar un número de hilo y para ‘reimplementar’ las señales ‘finalizadas’ y ‘iniciadas’ para incluir su número de hilo.

Me he centrado bastante en las señales entre la interfaz gráfica de usuario principal, los hilos y los trabajadores.

De manera similar, otras respuestas han sido un dolor para señalar que no son padres de QThread pero no creo que esto sea una preocupación real. Sin embargo, mi código también tiene cuidado de destruir los objetos QThread.

Sin embargo, no pude criar los objetos de trabajo, por lo que parece deseable enviarles la señal deleteLater (), ya sea cuando la función de subproceso haya finalizado o la GUI se haya destruido. He tenido mi propio código colgado por no hacer esto.

Otra mejora que sentí que era necesaria fue si se volvía a implementar el cierre de evento de la GUI (QWidget) de tal manera que se ordenaría a los hilos que se cerraran y luego la GUI esperaría hasta que todos los hilos estuvieran terminados. Cuando jugué con algunas de las otras respuestas a esta pregunta, conseguí errores QThread destruidos.

Quizás sea de utilidad para los demás. Ciertamente me pareció un ejercicio útil. Quizás otros conozcan una mejor manera para que un hilo anuncie su identidad.

 #!/usr/bin/env python3 #coding:utf-8 # Author: --<> # Purpose: To demonstrate creation of multiple threads and identify the receipt of thread results # Created: 19/12/15 import sys from PyQt4.QtCore import QThread, pyqtSlot, pyqtSignal from PyQt4.QtGui import QApplication, QLabel, QWidget, QGridLayout import sys import worker class Thread(QThread): #make new signals to be able to return an id for the thread startedx = pyqtSignal(int) finishedx = pyqtSignal(int) def __init__(self,i,parent=None): super().__init__(parent) self.idd = i self.started.connect(self.starttt) self.finished.connect(self.finisheddd) @pyqtSlot() def starttt(self): print('started signal from thread emitted') self.startedx.emit(self.idd) @pyqtSlot() def finisheddd(self): print('finished signal from thread emitted') self.finishedx.emit(self.idd) class Form(QWidget): def __init__(self): super().__init__() self.initUI() self.worker={} self.threadx={} self.i=0 i=0 #Establish the maximum number of threads the machine can optimally handle #Generally relates to the number of processors self.threadtest = QThread(self) self.idealthreadcount = self.threadtest.idealThreadCount() print("This machine can handle {} threads optimally".format(self.idealthreadcount)) while i  

Y el código del trabajador abajo.

 #!/usr/bin/env python3 #coding:utf-8 # Author: --<> # Purpose: Stack Overflow # Created: 19/12/15 import sys import unittest from PyQt4.QtCore import QThread, QObject, pyqtSignal, pyqtSlot import time import random class Worker(QObject): finished = pyqtSignal(int) intReady = pyqtSignal(int,int) def __init__(self, i=0): '''__init__ is called while the worker is still in the Gui thread. Do not put slow or CPU intensive code in the __init__ method''' super().__init__() self.idd = i @pyqtSlot() def procCounter(self): # This slot takes no params for j in range(1, 10): random_time = random.weibullvariate(1,2) time.sleep(random_time) self.intReady.emit(j,self.idd) print('Worker {0} in thread {1}'.format(self.idd, self.thread().idd)) self.finished.emit(self.idd) if __name__=='__main__': unittest.main()