QEventLoop instance for my "worker" to do work... - correct idea?

[jsulm]

@Dariusz said in QEventLoop instance for my "worker" to do work... - correct idea?:

like start function, then the thread dies at the end of the function?

Not if it has its own event loop

[Dariusz]

@jsulm said in QEventLoop instance for my "worker" to do work... - correct idea?:

@Dariusz said in QEventLoop instance for my "worker" to do work... - correct idea?:

like start function, then the thread dies at the end of the function?

Not if it has its own event loop

Is that not what I did with myWorker then? I'm bit lost how to set it up then :- (

[jsulm]

@Dariusz With QThread::run() you already get an event loop, there is no need to create one manually.
See https://doc.qt.io/qt-5/qthread.html#run
"The default implementation simply calls exec()"

https://doc.qt.io/qt-5/qthread.html#exec
Enters the event loop

[Dariusz]

@jsulm said in QEventLoop instance for my "worker" to do work... - correct idea?:

@Dariusz With QThread::run() you already get an event loop there is no need to create one manually.
See https://doc.qt.io/qt-5/qthread.html#run
"The default implementation simply calls exec()"

https://doc.qt.io/qt-5/qthread.html#exec
Enters the event loop

Hmm

So, in this case, I don't create myWorker(QObject) at all. I create myThreadWorker(QThread), reimplement def run() function and call exec() in that.

Then if I want to send function to it I can either do :
QMetaObject::invokeMethod(myThreadWorker,={}) // giving myThreadWorker as parent, should mean that the thread will execute it?
or
send myQEvent() subclass of QEvent to it.
I suppose I need to override def event() on myThreadWorker to capture events it receives and then handle my events properly?

TIA

[jsulm]

@Dariusz Take a look at documentation https://doc.qt.io/qt-5/qthread.html
There is an example how to use worker objects.

Do you really need events to communicate with the thread? The easiest way is actually to use signals/slots.

[Dariusz]

@jsulm said in QEventLoop instance for my "worker" to do work... - correct idea?:

@Dariusz Take a look at documentation https://doc.qt.io/qt-5/qthread.html
There is an example how to use worker objects.

I went over the QThread docs - briefly... (I've read it lots of time in past bust just to refresh...)

1st examples shows the workflow with moving object to thread which is what I did above in pySide2.
The second example talks about reimplementing run() functions.

In both of these examples as far as I can tell, the thread will die at the end of given functions. I cant let it die, I want it to be available and provide work connection with another library for as long as I want.

So I'm lost again as to how I can use it.

Do you really need events to communicate with the thread? The easiest way is actually to use signals/slots.

I need to be able to send jobs to that thread with different priority of execution, so some jobs might need to happen before other ones.

---

Edit from what I can read
"Thus, a developer who wishes to invoke slots in the new thread must use the worker-object approach; new slots should not be implemented directly into a subclassed QThread."

This tells me that I do in fact need myWorker(QObject) class and the moveToThread action to have my slots/signals/ executed in other thread, as run() does not allow for it to happen.

[jsulm]

@Dariusz said in QEventLoop instance for my "worker" to do work... - correct idea?:

I cant let it die

Then call exec() in run() - it will start the event loop.

"I need to be able to send jobs to that thread with different priority of execution, so some jobs might need to happen before other ones" - I still don't see a need for events. Send the jobs as signals. Priority handling is something you need to implement.

[Dariusz]

@jsulm said in QEventLoop instance for my "worker" to do work... - correct idea?:

@Dariusz said in QEventLoop instance for my "worker" to do work... - correct idea?:

I cant let it die

Then call exec() in run() - it will start the event loop.

"I need to be able to send jobs to that thread with different priority of execution, so some jobs might need to happen before other ones" - I still don't see a need for events. Send the jobs as signals. Priority handling is something you need to implement.

Hmmm yeah the exec() would keep it alive allowing me to send stuff to that thread. But it would not be processed by that thread according to this documentation :

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. Thus, a developer who wishes to invoke slots in the new thread must use the worker-object approach; new slots should not be implemented directly into a subclassed QThread.

Priority handling is something you need to implement.

Well yes, and no. QEventLoop and now that I can read QEvents have priority options. So if I create event and send it to that thread, that event will be executed in accordance to the priority of it. So Qt offers priority control as well. I just have to use QEvents when sending jobs to Thread... Not sure how to send event to thread yet... but event would be something like:

class myEvent : public QEvent(){
/// specify type to MaxUser+xx
public:
    myEvent()
    ~myEvent()
    std::function<void> mFunction;
}

Then I can send that to either myThreadWorker(QThread) or myWorker(QObject). Not sure which yet as I need to read a bit more...

---

As far as I can tell this is somewhat the workflow > https://stackoverflow.com/questions/6208339/qt-correct-way-to-post-events-to-a-qthread
https://doc.qt.io/qt-5/qcoreapplication.html#postEvent

[jsulm]

@Dariusz Well, of course you should not send signals to QThread instance as it is not the thread itself, it is just an object which manages the thread. Instead you send signals to objects living in that thread (use moveToThread to move objects to the thread).

[Dariusz]

@jsulm said in QEventLoop instance for my "worker" to do work... - correct idea?:

@Dariusz Well, of course you should not send signals to QThread instance as it is not the thread itself, it is just an object which manages the thread. Instead you send signals to objects living in that thread (use moveToThread to move objects to the thread).

Yeah, which again begs the question. how do I start the thread and object without object closing down the thread. So we use 1st solution from docs. But that will end when function finish.... So how do I start the thread with object and not let it finish but still run event loop to process events... ?

[Christian Ehrlicher]

@Dariusz said in QEventLoop instance for my "worker" to do work... - correct idea?:

So how do I start the thread with object and not let it finish but still run event loop to process events... ?

By simply starting the QThread with QThread ::start() and not overwriting QThread::run()

[Dariusz]

@Christian-Ehrlicher The thread don't get autodeleted once it runned its empty function? o.O I need to test it! :D