Discussion about "Threads, Events and QObjects" article

[dangelog]

[quote author="Volker" date="1298497988"]The two articles are identical. My "version" (that without the underscores) is only a link to the actual article. The reason is, that the old version of the link is referred in some other articles and in a blog entry.

Unfortunately it does not redirect to the actual article but pulls in its content and it does not leave a message of doing so.[/quote]

I totally missed what happened :) Thank you for setting everything up properly!

[James G]

Sorry for taking a year to get back Peppe, but thanks for your reply at http://qt-project.org/forums/viewreply/25457/. I tend to get busy with big projects and don't worry about past problems I've already fixed.

It took me a few minutes to get my head around what you were saying but after carefully re-reading the Qt documentation it finally hit me. It does make sense that if the objects are copied like you show in the first thread (or using a mutex if from another thread) then things are safe. This also says that passing a static copy of an object to another thread using a signal is safe because the copy operation happens on the original thread. Signaling with a pointer to the original object is another matter, however, and should not be done.

I guess my real gripe was the fact that QDateTime was not listed as implicitly shared when it really was. You can copy some static objects like QDate or QTime in the way I was doing without crashing because they only contain static members and are not implicitly shared. One might not get the right result due to synchronization problems with the underlying data, but it won't cause a crash.

I will update my article soon with a link back to here.

[joonhwan]

I think now I start understaing in the relevant "wiki page":http://qt-project.org/wiki/Threads_Events_QObjects . Thanks great articles!

After reading it second time while I'm translating it into Korean, I found following statement is quite ambiguous.

bq.
A thread event loop delivers events for all QObjects that are living in that thread; this includes, by default, all objects that are created into that thread, or that were moved to that thread (more info about this later). We also say that the thread affinity of a QObject is a certain thread, meaning that the object is living in that thread. This applies to objects which are built in the constructor of a QThread object:

Because, any object that are built in the constructor of QThread couldn't live the thread represented by that QThread object, I feel like that the last statement sounds misleading doesn't it?

[andre]

Not really, as those are not created in that thread. Note that thread != QThread. The constructor of QThread runs in the same thread as the code that created the QThread object itself, not in the thread that QThread manages.

[joonhwan]

[quote author="Andre" date="1331800273"]Not really, as those are not created in that thread. Note that thread != QThread. The constructor of QThread runs in the same thread as the code that created the QThread object itself, not in the thread that QThread manages. [/quote]

Yeah, so the last statement might be "This doesn't apply to objects which are built in the constructorof a QThread object:" I thought.

[andre]

No, I think you are misunderstanding this piece of text and the accociated piece of code. The fact that objects live in the thread that created them also applies to those objects created in the constructor of a subclassed QThread, where the thread is still the thread creating the object. If you read on, you will see an example that explains this further. The text below explains exactly this issue. So really, the text is correct.

[KA51O]

So an object created in the constructor of a QThread (or subclass of QThread) is in the context of the thread that created the QThread object. Objects which are created in the run(..) method of the QThread object or which are moved to the context of the thread, which is managed by the QThread object, are in the context of that ("new") thread.

Correct ?

[andre]

Yes, that sounds correct.

[Pu1]

Thx 4 this great article!

There are still two things, which are not clear to me.

1. How do I stop the thread's event loop, if it's executing an inifitely task (like reading data from serial port)? (It is not busy all the time, but it needs to run the event loop to be notified, when new data arrives).
   Before reading this article I always did thread->moveToThread(thread); with the thread and then later called QMetaObject::invokeMethod(thread, "quit");
   without moveToThread(thread) this won't work.

Maybe your wondering why I read the serial port from a different thread. The reason is, that when I'm moving the application's window with the mouse, the serial port won't receive any data until I release the window. It's probably some kind of bug in QextSerialPort, but I was able to fix it by using a thread for reading the serial port (but still event based).

2. I'm not sure if I got it write, how it is determined, if Queued or DirectConnection is used.
   My current understanding is that when using AutoConnection on every emit it is checked, if the thread which executes the emit statement is the same as the thread in which the objects whichs slot is going to be invoked lives in. If the threads are the same, then the slot is called directly, otherwise the invocation is queued.

Before reading this article I always thought, that at the moment at which QObject::connect with AutoConnection is called, it is determined, if a Direct or Queuedconnection is used and then this connection type will be used for all further emits.

Is the threadaffinity checked on every emit, or just when doing connect?

[amleto]

in this section

[quote]
A much better and simpler way of achieving the same result is simply using timers, i.e. a QTimer [doc.qt.nokia.com] object with a 1s timeout, and make the doWork() method a slot:

class Worker : public QObject
{
Q_OBJECT

public:
Worker() {
connect(&timer, SIGNAL(timeout()), this, SLOT(doWork()));
timer.start(1000);
}

private slots:
void doWork() {
/* ... */
}

private:
QTimer timer;
};

All we need is a running event loop, then the doWork() method will be invoked each second.
[/quote]
the timer needs to have its parent set to Worker instance otherwise it wont change thread when the owning class instance does.

[JKSH]

Hello Peppe, I've started revamping the official overview documentation for thread usage in Qt, and I'd like to incorporate some of the information from your article. Is that ok?

[great88]

Is it OK to spawn new thread inside a readyRead() handler and then access and write to tcpsockets ( from the parent thread ) from that thread ? It looks to me that this is not good because sometimes clients are not receiving data . What is the proper way to do this ?

[JKSH]

[quote author="great88" date="1376933337"]Is it OK to spawn new thread inside a readyRead() handler and then access and write to tcpsockets ( from the parent thread ) from that thread ? It looks to me that this is not good because sometimes clients are not receiving data . What is the proper way to do this ?[/quote]If your TCP socket is in the parent thread, you cannot write to it from a new thread.

There have been many posts about combining QTcpSocket and QThread recently. Search the forum, and you should find plenty of info.