Discussion about threads, moveToThread etc.

[yanbellavance]

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.

[giesbert]

This warning is related to the "physical" thread, not the QThread object. Running it in a worker thread MUST be save, event if you don't call moveToThread on the Thread. But only, if the QIODevice has not the QThread object as parent.

[LinusA]

[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

[yanbellavance]

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.

[yanbellavance]

[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.

[Aksh]

Sorry friend but I am not clear where we should overwrite the run() and moveToThread()....so please clear it first.
Thanx in advance.

[JKSH]

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.

[Aksh]

I knew these tow ways but I realy confused when and where I should used which way(overwrite the run() or moveToThread()).

I request you to reply on this.

Thanx in advance.....

[Aksh]

Hi JKSH,
Tnq very much for your reply.
I knew these tow ways but I realy confused when and where I should used which way(overwrite the run() or moveToThread()).

I request you to reply on this.

Thanx in advance.....

[dbzhang800]

Hi Ak@sh,

you can find answer of your question in the documentation.

http://qt-project.org/doc/qt-5.1/qtcore/thread-basics.html

[JKSH]

[quote author="Ak@sh" date="1374741806"]Hi JKSH,
Tnq very much for your reply.
I knew these tow ways but I realy confused when and where I should used which way(overwrite the run() or moveToThread()).[/quote]Hi Ak@sh, you're welcome.

In general, I would:

• Use moveToThread() if I want two-way communication with the thread using signals+slots or events.
• Reimplement run() if my thread is very simple, and I don't need to send signals/events to the thread..

If you tell us what you plan to do with your threads, we can give you better advice.

[Aksh]

Hi JKSH,

thanx for your reply.

In my current projct I already used overwrite the run() method for thread.But I confused when I saw moveToThread() Beacuse,
Some experts says overwrite the run() is not a proper way to thread.

please once see this link:-
http://mayaposch.wordpress.com/2011/11/01/how-to-really-truly-use-qthreads-the-full-explanation/

I request you to reply on this.

Thanx in advance…..

[dbzhang800]

Hi, the blog goes from one extreme to the other.

In fact, both are right usages. The documentation will be useful for you http://qt-project.org/doc/qt-5.1/qtcore/thread-basics.html

---

BTW, if you are interested in the topic, you can have a look at

http://woboq.com/blog/qthread-you-were-not-doing-so-wrong.html

[Aksh]

Nice Documenaion and han for that.
They mention this two points -
If you do not really need an _ -event loop-_ in the thread, you should subclass.
If you need an -event loop- and handle signals and slots within the thread, you may not need to subclass.

What they exactly mean with EVENT LOOP ???
I know might this is very silly que for you but please....

[JKSH]

An event loop is an infinite loop that processes signals and events. It waits for signals/events to arrive, then it calls functions to handle them.

The main thread starts an event loop by calling QCoreApplication::exec():
@
int main(int argc, char *argv[])
{
QApplication a(argc, argv);
// ...

// This line starts an (infinite) event loop, then
// returns its status when the loop is exited
return a.exec();

}
@

QThread starts an event loop by calling QThread::exec():
@
void QThread::run()
{
// This line starts an (infinite) event loop, but
// doesn't return an exit status value
this->exec();
}
@

Also, see "this page":http://qt-project.org/doc/qt-5.1/qtcore/threads-qobject.html

[Aksh]

Hii..gm.
Thnx for ur important time and reply on my query.
I am not relates the things.
come again on our main point and please comfirm me that then when we you should subclass QThread class for thread then there is no EVENT LOOP?

[dbzhang800]

Hi,

At first, I don't think other can make you understand this in short word, if the documentation can not help you.

But I think you can easily find with method is suitable when you writing your application.

1. Subclass the QThread and re-implement the QThread::run()
2. If you find that slots doesn't work correctly without moveToThread(this), then you are doing it wrong. Please use another method.
   3 Otherwise, you are doing it right.

[quote author="Ak@sh" date="1375074051"]Hii..gm.
Thnx for ur important time and reply on my query.
I am not relates the things.
come again on our main point and please comfirm me that then when we you should subclass QThread class for thread then there is no EVENT LOOP?[/quote]

[Aksh]

please can you give me one simple example or senario which shows clearly need of moveToThread(this) over subclass QThread...

[JKSH]

[quote author="Ak@sh" date="1375085561"]please can you give me one simple example or senario which shows clearly need of moveToThread(this) over subclass QThread...[/quote]It's easier to do it the other way round. Please tell us what you want to do, and we'll explain which method you need.

The experts told people to stop subclassing QThread because many people did it wrongly. It is easier to make mistakes when subclassing QThread. But, you are still allowed to subclass QThread.

[Aksh]

In my project from one hardware I have to receive data from serial and acording to updated data I have to update my GUI.Paralally user can perform some operations on GUI(like delete/add/update etc...).

So In above my requirement 3 threads will work -

1. main thread i.e. GUI
   2.thread which send request to H/w
   3.thread which continuously waiting for data to receive from H/w.