Main thread - worker thread communication.

Are you sure this is correct?

Code:

---

class WorkerThread(QtCore.QThread):
    def __init__(self, start, end):
        QtCore.QThread.__init__(self)
        self.start = start
        self.end = end

---

You have a variable called start and then you call start as a method. Try using a different name here. Maybe that's the problem.

Quote:

---

Originally Posted by wysota

Are you sure this is correct?

Code:

---

class WorkerThread(QtCore.QThread):
    def __init__(self, start, end):
        QtCore.QThread.__init__(self)
        self.start = start
        self.end = end

---

You have a variable called start and then you call start as a method. Try using a different name here. Maybe that's the problem.

---

...
.....
.......

What can i say...i am just an idiot...The problem was right just under my nose. That was it! I renamed start to pstart and all working ok.
A MILLION thanks wysota!!!

I will now just experiment with the "proxy" style to send the signal.

Thanks again! :)

I have made an exact (i hope) Python version of your C++ code, i post it below.
The thing seems to be working ok, the progress bar is updated correctly and the main thread (form) remains responsive.
(I do not like the fact that i use 3 classes just to do that but anyway...)

So, we connect the propagate SIGNAl to the Emiter one and thus we get the SLOT setValue of the progress bar to be fired when the SIGNAL is sent.

In a previous version of mine, you have said that in the way i had wrote it was a little dangerous because we might not be sure from what thread the code will be executed.
As i study more closely your code (and my Python implementation of this), what make you sure that in this way the function will be called from the correct thread ?


Here is the code:

Code:

---

import sys
from PyQt4 import QtCore, QtGui
from calculatorform_ui import Ui_CalculatorForm
from ui_countNumbers import Ui_MainWindow
from time import sleep
 
class Emiter(QtCore.QObject):
    def __init__(self):
        QtCore.QObject.__init__(self)
 
    def emitSignal(self, val):
        self.emit(QtCore.SIGNAL("updateProgress(int)"), val)
 
class WorkerThread(QtCore.QThread):
    def __init__(self):
        QtCore.QThread.__init__(self)
        self.pstart = 0
        self.pend = 0
 
    def run(self):
        e = Emiter()
        propagate = QtCore.SIGNAL("propagate(int)")
        QtCore.QObject.connect(e, QtCore.SIGNAL("updateProgress(int)"), self, propagate)
 
        for x in range(self.pstart, self.pend):
            sleep(1)
            e.emitSignal(x)
 
class CountNumbersForm(QtGui.QMainWindow):
    def __init__(self, parent=None):
        QtGui.QMainWindow.__init__(self, parent)
        self.ui = Ui_MainWindow()
        self.ui.setupUi(self)
 
    @QtCore.pyqtSignature("")
    def on_start_clicked(self):
        worker.pstart = count.ui.spFrom.value()
        worker.pend = count.ui.spTo.value() + 1
        self.ui.progress.setRange(worker.pstart, worker.pend)
        worker.start()
 
    def updateProgress(self, val):
        self.ui.progress.setValue(val)
 
 
if __name__ == "__main__":
    app = QtGui.QApplication(sys.argv)
    count = CountNumbersForm();
    worker = WorkerThread();
    QtCore.QObject.connect(worker, QtCore.SIGNAL("propagate(int)"), count.ui.progress.setValue, QtCore.Qt.QueuedConnection)
    count.show()
    sys.exit(app.exec_())

---

I mean, if i emit entirely the Emit class and the like and replace WorkerThread class with this:

Code:

---

class WorkerThread(QtCore.QThread):
    def __init__(self):
        QtCore.QThread.__init__(self)
        self.pstart = 0
        self.pend = 0
 
    def run(self):
        for x in range(self.pstart, self.pend):
            sleep(1)
            self.emit(QtCore.SIGNAL("updateProgress(int)"), x)

---

what do you think will go wrong ? I read PyQt4 docs and says that the mechanism is able to "Connections may be made across threads." Isn't it our occassion here and particularly because i use queued connections ?? (QtCore.Qt.QueuedConnection)

Thanks again!

If you force queued connections, then all will be ok. The thing that makes me sure my approach will work is that the "emit" object is created (and thus handled) in the worker thread (because it's created in the run() method that is executed in context of the worker thread). This means that if I call a method that emits a signal and both the caller (run()) and the callee (Emit instance) are in the same (worker) thread, I can be sure that the signal will be queued because the receiver is in the GUI thread. Now if the callee (QThread object) was in a different thread than the caller (run()) I don't know how Qt would behave. You can check Qt sources and see for yourself - maybe the trick I made was not needed. You can also have the same effect without the Emit object - just move the QThread object to the thread it represents.

Quote:

---

Originally Posted by wysota

If you force queued connections, then all will be ok. The thing that makes me sure my approach will work is that the "emit" object is created (and thus handled) in the worker thread (because it's created in the run() method that is executed in context of the worker thread). This means that if I call a method that emits a signal and both the caller (run()) and the callee (Emit instance) are in the same (worker) thread, I can be sure that the signal will be queued because the receiver is in the GUI thread. Now if the callee (QThread object) was in a different thread than the caller (run()) I don't know how Qt would behave. You can check Qt sources and see for yourself - maybe the trick I made was not needed. You can also have the same effect without the Emit object - just move the QThread object to the thread it represents.

---

Ok, i see...very helpfull post indeed. The "queued connections", as i saw it, are a very nice way to keep things simple and not complicated. regarding the Singals and Slots mechanism and the communication over different threads. (In fact, i like it even more that the respective C# stuff)
Is there any "catch" with that ? Performance problems or something else ?

They are a bit slower as you have to serialise all the arguments and then recreate them back in the other thread when the slot is executed. And there is of course the latency between emiting the signal and the other thread processing it. Oh... and the other thread has to have an event loop running of course.