Discussion about threads, moveToThread etc.
-
[quote author="Andre" date="1311866425"]So: you have to make sure you delete the created object yourself at an appropriate time.[/quote]
The easiest way to achieve this is to create the first object as object on the stack, and put all other as children of it, Then everything will be deleted correctly :-)
-
/agree. Is there a way to split a thread? guess so :)
-
bq. Warning: QObject: Cannot create children for a parent that is in a different thread.
I don't know what I did yesterday trigger that message , i was trying a couple of things but I put the code back to what it was. I think it is unrelated and I have a pretty good idea where it happened. I then took a look at my run function and I did find 1 object created there who's parent is the QThread (first and only one). What I don't understand is: aren't they the same thread? The parent of the object declared in run is QThread and moveToThread has been called previously to entering run. I removed the parent but I still can't trigger slots in the qthread without an event loop. -
I think you can boil it all down to this: Where is your object created? If it's in "QThread::run()", then it got it's own concurrent OS-based thread. If not, then it's all in Qt's main GUI thread.
Even if you create a QThread object, its signals and slots basically "live" in the main thread (as in: the thread where you created the QThread).
QThread is not so much a real OS-thread, but more like "A wrapper / container which provides a method run, which will be executed in its own thread".
So you either go the "low level road", re-implement run(), preferrably don't call exec(), and do your processing. Data exchange will have to be protected (by mutexes, semaphores, etc.).
Or, you could leave run()'s default implementation (which calls exec()). Then you call, from your main (GUI) thread, .moveToThread() on some objects. Specifically: On those objects, whose events (slots) you want to have processed by another OS thread.
So if you have an QObject MyWorker, and a slot "doWork()", and then you do:
@
MyWorker someWorker;
// now connect some signal to SLOT("doWork()") of someWorker
QThread workingThread;
someWorker.moveToThread(workingThread);
workingThread.start();
@
Then this means, whenever the doWork() slot is called, it will be executed in the context of it's own OS thread (the workingThread's thread).I personally wouldn't mix those two. EITHER don't subclass QThread at all, don't touch its constructor etc. Do everything signal-slot based, and with .moveToThread().
OR, you do implement QThread and run(), but you don't call exec() and don't do .moveToThread with this specific class. Edit: or, if you have to, call exec() from this current QThread::run() context, but don't do moveToThread on other objects.
Just my 2 cents :-)
-
[quote author="LinusA" date="1311880952"]I think you can boil it all down to this: Where is your object created? If it's in "QThread::run()", then it got it's own concurrent OS-based thread. If not, then it's all in Qt's main GUI thread.
Even if you create a QThread object, its signals and slots basically "live" in the main thread (as in: the thread where you created the QThread).
[/quote]What you are saying is true ONLY if you do not call moveToThread.
If you don't call moveToThread on QThread then both the main thread and QThread will have the same address, if you do call moveToThread then QThread has the same address as objects created inside the run function. I just did the test I can confirm this.
if you want to test it out just put this in the run function:
@
QUdpSocket * FcpSocket; // I declared this pointer in the class but the new is in run so it doesn't matter
this->FcpSocket=new QUdpSocket(this);
QThread* sockThread=FcpSocket->thread();
QThread* fpsEngineThread=this->thread();
@
and before this either call moveToThread or not and see the difference, with and without the call to moveToThread.Also, I called moveToThread and I do not call exec inside run on purpose, that is how I needed it to be.
That is why you should call moveToThread when using functions that should not be called from the mainthread.P.S. I am on linux platform -
Gerolf, from my previous post you can see that in deed, if you do not call moveToThread, then you should never use this as parent to objects created in run, if you do then both the object parent and QThread will have same address.
-
[quote author="yan bellavance" date="1311978655"]Gerolf, from my previous post you can see that in deed, if you do not call moveToThread, then you should never use this as parent to objects created in run, if you do then both the object parent and QThread will have same address.[/quote]
Not the same adress, the same thread affinity :-)
If you do not use signal/slot inside a thread, you need no mopveToThread to access QObejsct inside other threads as their attached one. moveToThread is only needed for signal&slot; stuff and auto connections or to find the correct event loop for a queued slot or function.By the way, moveToThread is not a method inside QThread, it's inside QObject sao it can be called in any QObject. But why do you need the QThread to be assigned to it's own hosted thread? A better sollution (from my POV) is to give the thread slots and signals. The users of the thread can connect to the slots, which itself emit a signal that is attached inmsidethe run method with objects that live inside run. Then each object has the correctr thread affinity and it works.
-
I am doing this to separate the QThread from the main thread because I am using:
@bool QIODevice::waitForBytesWritten ( int msecs )
bool QIODevice::waitForReadyRead ( int msecs )
@These functions should not be used in a QThread that has the same thread affinity as the main thread. Notice the warning about these functions:
bq. Warning: Calling this function from the main (GUI) thread might cause your user interface to freeze.
I have seen other things happen as well: it can create dereferencing errors, somehow qt gets confused and tries for example to delete memory that has a dereferencing count of 0 which causes an exception. By changing the thread affinity of my QThread, I take its memory out of the main thread which eliminated this problem.
So basically I have done this to protect data.
-
[quote author="yan bellavance" date="1312215886"]I am doing this to separate the QThread from the main thread because I am using:
@bool QIODevice::waitForBytesWritten ( int msecs )
bool QIODevice::waitForReadyRead ( int msecs )
@
[/quote]
As I understand it, in this case it would be better to use the signals "bytesWritten" and "readyRead". See http://developer.qt.nokia.com/wiki/Threads_Events_QObjects#2b40afeff6025af55f25a6c7ea5ab3bc -
well it is not safe. And I know this from experience. I had spent a lot of time on this a while back when I was developing that part and I can assure you that it was causing problems. The code without moveToThread would crash once in a while (though it was a rare occurrence it was still unacceptable). The code with moveToThread never crashed. I refer you to the documentation once more:
bq.
This function can operate without an event loop. It is useful when writing non-GUI applications and when performing I/O operations in a non-GUI thread.Now if it is not safe but is supposed to then there is a Qt bug that needs to be resolved. I reported it but nothing was ever done about it so I took the QThread out of there.
-
[quote author="LinusA" date="1312218342"]
As I understand it, in this case it would be better to use the signals "bytesWritten" and "readyRead".[/quote]Not when a polling technique is used, which is my case. There is no reason why I should not be allowed to do this otherwise, might as well take those functions out of the Qt. If you look at the Blocking Fortune Client example from Qt you will see that this is how they implemented it.
-
Hi Ak@sh, see http://qt-project.org/doc/qt-5.1/qtcore/qthread.html
By the way, this thread is 2 years old. It's best to start a new thread next time.
