How to use QThread correctly in pyqt with moveToThread()?

Solution 1:

The default run() implementation in QThread runs an event loop for you, the equivalent of:

class GenericThread(QThread):
    def run(self, *args):
        self.exec_()

The important thing about an event loop is that it allows objects owned by the thread to receive events on their slots, which will be executed in that thread. Those objects are just QObjects, not QThreads.

Important note: the QThread object is not owned by its own thread [docs]:

It is important to remember that a QThread instance lives in the old thread that instantiated it, not in the new thread that calls run(). This means that all of QThread's queued slots and invoked methods will execute in the old thread [e.g. the main thread].

So you should be able to do this:

class GenericWorker(QObject):
    def __init__(self, function, *args, **kwargs):
        super(GenericWorker, self).__init__()

        self.function = function
        self.args = args
        self.kwargs = kwargs
        self.start.connect(self.run)

    start = pyqtSignal(str)

    @pyqtSlot()
    def run(self, some_string_arg):
        self.function(*self.args, **self.kwargs)

my_thread = QThread()
my_thread.start()

# This causes my_worker.run() to eventually execute in my_thread:
my_worker = GenericWorker(...)
my_worker.moveToThread(my_thread)
my_worker.start.emit("hello")

Also, think carefully about what happens with the result of self.function, which is currently discarded. You could declare another signal on GenericWorker, which receives the result, and have the run() method emit that signal when it's done, passing the result to it.

Once you get the hang of it and realize you don't and shouldn't subclass QThread, life becomes a lot more straightforward and easier. Simply put, never do work in QThread. You should almost never need to override run. For most use cases, setting up proper associations with a QObject to a QThread and using QT's signals/slots creates an extremely powerful way to do multithreaded programming. Just be careful not to let the QObjects you've pushed to your worker threads hang around...

http://ilearnstuff.blogspot.co.uk/2012/09/qthread-best-practices-when-qthread.html

Solution 2:

I was attempting to use qris's example in my application, but kept having my code run in the my main thread! It is the way the signal that he declared to call run!

Basically, when you connect it in the constructor of the object, the connection will exist between two objects in the main thread - because the QObject's properties belong to the thread that created them. When you move the QObject to your new thread, the connection doesn't move with you. Take away the line that connects your signal to the run function, and connect it after you move the worker to its new thread!

The relevant change from qris's answer:

class GenericWorker(QObject):
    def __init__(self, function, *args, **kwargs):
        super(GenericWorker, self).__init__()

        self.function = function
        self.args = args
        self.kwargs = kwargs

    start = pyqtSignal(str)

    @pyqtSlot
    def run(self, some_string_arg):
        self.function(*self.args, **self.kwargs)

my_thread = QThread()
my_thread.start()

# This causes my_worker.run() to eventually execute in my_thread:
my_worker = GenericWorker(...)
my_worker.moveToThread(my_thread)
my_worker.start.connect(my_worker.run) #  <---- Like this instead 
my_worker.start.emit("hello")

Solution 3:

I've tried both @qris and @MatthewRunchey approaches.

With the @pyqtSlot decorator Qt checks the "location" of the worker instance when the signal is emitted: even if the connection was made before moveToThread emitting the signal after moveToThread executes the slot in the worker thread.

Without the @pyqtSlot decorator Qt freezes the "location" of the worker instance the moment when the connection was made: if it was before moveToThread, it is bound to the main thread, and the slot code keeps being executed in the main thread even if the signal is emitted after moveToThread call.

Connections made after moveToThread bind the slot to be executed the worker thread in both cases.

Code:

import threading
from PyQt5.QtCore import (QCoreApplication, QObject, QRunnable, QThread,
                          QThreadPool, pyqtSignal, pyqtSlot)

class Worker(QObject):
    def __init__(self):
        super(Worker, self).__init__()
#        self.call_f1.connect(self.f1)
#        self.call_f2.connect(self.f2)

    call_f1 = pyqtSignal()
    call_f2 = pyqtSignal()

    @pyqtSlot()
    def f1(self):
        print('f1', threading.get_ident())
    
    @pyqtSlot()
    def f2(self):
        print('f2', threading.get_ident())

app = QCoreApplication([])
print('main', threading.get_ident())
my_thread = QThread()
my_thread.start()

my_worker = Worker()
my_worker.call_f1.connect(my_worker.f1)
my_worker.call_f1.emit()
my_worker.moveToThread(my_thread)
my_worker.call_f2.connect(my_worker.f2)
my_worker.call_f1.emit()
my_worker.call_f2.emit()
sys.exit(app.exec_())

With decorator:

main 18708
f1 18708
f1 20156
f2 20156

Without decorator:

main 5520
f1 5520
f1 5520
f2 11472

PS Connecting in the worker __init__ method is obviously equivalent to connecting before moveToThread in the main thread.

(tested under PyQt5, win64).

Solution 4:

I know this is an old question, but I found this relevant and fairly recent article: Use PyQt's QThread to Prevent Freezing GUIs.

It is pretty much the minimal Python implementation of the approach given in How To Really, Truly Use QThreads and it provides a very clean example of how to use QObject.moveToThread().

I copied the code and pasted it here for reference and discussion (I'm not the author):

from PyQt5.QtCore import QObject, QThread, pyqtSignal
# Snip...

# Step 1: Create a worker class class Worker(QObject):
class Worker(QObject):
    finished = pyqtSignal()
    progress = pyqtSignal(int)

    def run(self):
        """Long-running task."""
        for i in range(5):
            sleep(1)
            self.progress.emit(i + 1)
        self.finished.emit()

class Window(QMainWindow):
    # Snip...
    def runLongTask(self):
        # Step 2: Create a QThread object
        self.thread = QThread()
        # Step 3: Create a worker object
        self.worker = Worker()
        # Step 4: Move worker to the thread
        self.worker.moveToThread(self.thread)
        # Step 5: Connect signals and slots
        self.thread.started.connect(self.worker.run)
        self.worker.finished.connect(self.thread.quit)
        self.worker.finished.connect(self.worker.deleteLater)
        self.thread.finished.connect(self.thread.deleteLater)
        self.worker.progress.connect(self.reportProgress)
        # Step 6: Start the thread
        self.thread.start()

While the accepted answer does work, I think the above approach is highly preferable, because

  • it properly quits the thread when the worker has finished,
  • it performs clean-up for both the thread and the worker using .deleteLater, and
  • it does not rely on the pyqtSlot() decorator to actually run in another thread (I tested this).

Note: In the above approach, the thread – and thus the worker, being connected to the thread.started signal – is started "manually", and the worker emits a finished signal when its work is done. However, in the accepted answer, the worker is started through a start signal, but there is no mechanism indicating whether its work is done.