QThread with signals and slots

dangelog

The connect itself is fine, and if you've understood my article, specifying Qt::QueuedConnection is useless. Is an event loop running in the thread MyClass is living in?

goocreations

No, no event loop is running in MyClass

dangelog

Not in "MyClass", in the thread your MyClass object is living in. If not, read the article and understand what's wrong.

giesbert

Hi goocreations, queued connections need an event loop running in the thread that own sthe object that contains the slot. So if the creating thread is the main thread, has yout main thread an event loop?

andre

[quote author="goocreations" date="1294519650"]Thanks Andre, I'm trying your way now:

I've created a (derived) instance of QObject (which includes a signal), connected the objects signal to my update slot (is that correct?)a nd I've used moveToThread. But how do I emit the signal from my thread, since MyThread doesn't have a signal at the moment?[/quote]
You start work in your thread by giving your worker object a slot. In the default implementation, your thread will get an event loop (run() calls exec()), so you can invoke a slot in it. You can invoke that slot by connecting a signal to it from the main thread, or by using QMetaObject::invokeMethod. In the latter case, don't forget to include the Qt::QueuedConnection flag, otherwise you make a direct method call and your slot won't be executed in the new threads' context, but in the main threads' context.

Satmosc

[quote author="Andre" date="1294519136"]The main problem is, that goocreations is using QThread in the wrong way. QThread is a class managing a thread. It is not the thread itself.

This is a frequently returning topic, mostly because of documentation issues in this respect in Qt. The recommended way of working with threads in Qt has changed since the documentation was
[quote author="Andre" date="1294572814"][quote author="goocreations" date="1294519650"]Thanks Andre, I'm trying your way now:

I've created a (derived) instance of QObject (which includes a signal), connected the objects signal to my update slot (is that correct?)a nd I've used moveToThread. But how do I emit the signal from my thread, since MyThread doesn't have a signal at the moment?[/quote]
You start work in your thread by giving your worker object a slot. In the default implementation, your thread will get an event loop (run() calls exec()), so you can invoke a slot in it. You can invoke that slot by connecting a signal to it from the main thread, or by using QMetaObject::invokeMethod. In the latter case, don't forget to include the Qt::QueuedConnection flag, otherwise you make a direct method call and your slot won't be executed in the new threads' context, but in the main threads' context.
[/quote]

written. It is usually better not to add signals, let alone slots, to QThread. Instead, create a QObject (derived) instance, and call moveToThread on it to move it to the thread. Put your signals and slots in this worker object instead.

See "this blog":http://labs.qt.nokia.com/2010/06/17/youre-doing-it-wrong/ for details.[/quote]

Hi , I was reading this old post , Then I was surprised after reading that documents are old and not correct way.
I read several post in Qt blog , with different Idea.... what is really the correct way ?
I am also confused now , what is the correct way of using movetothread !!!!

by the way , I always use movetothread and I use signal and slots and I never had problem but I prefer to be on the correct way on implementation

thanks

andre

Reference the blog and "this":http://developer.qt.nokia.com/wiki/ThreadsEventsQObjects wiki entry. Only based on the official Qt documentation, it is way too easy to get it wrong. Also, do not, please, use moveToThread(this) inside your QThread subclass. You probably don't understand what that does exactly, and what the consequences are.

Satmosc

Thank you very much. You are right. I am a bit confused now about movetothread while I know it is used later in the thread for events and ...

I need to get help by reading a source code which has correct implementation.
As I remember in the documents , ::Start() should not be called from the thread itself !!! while I see in the code "queuedcustomtype" (attached in the Qt Sources) the start has been called from a method inside the Thread Subclass !!!!! ?

dangelog

[quote]I need to get help by reading a source code which has correct implementation. As I remember in the documents , ::Start() should not be called from the thread itself ![/quote]

What do you mean with that? It's supposed to be called from the thread your thread object is living in. Calling a custom method foo() which in turns calls start() is perfectly fine.

andre

Copy/paste from the mentioned wiki entry:

@
class Worker : public QObject
{
Q_OBJECT

public slots:
void doWork() {
/* ... */
}
};

/* ... */
QThread *thread = new QThread;
Worker *worker = new Worker;
connect(obj, SIGNAL(workReady()), worker, SLOT(doWork()));
worker->moveToThread(thread);
thread->start();
@

Satmosc

[quote author="Andre" date="1306745564"]Copy/paste from the mentioned wiki entry:

@
class Worker : public QObject
{
Q_OBJECT

public slots:
void doWork() {
/* ... */
}
};

/* ... */
QThread *thread = new QThread;
Worker *worker = new Worker;
connect(obj, SIGNAL(workReady()), worker, SLOT(doWork()));
worker->moveToThread(thread);
thread->start();
@
[/quote]

Thank you very much. so , it means SubClassing is already over since Qt 4.4(which it is not a Abstract class anymore) . so , I should use thread always this way !?
by the way , the Qt wiki looks excelent .

@peppe : in that example from Qt Sources I see that the thread::Start has been called from thread subclass and not the thread that object lives in.

andre

It is not impossible to subclass QThread and use it that way, but it is no longer the recommended way to do things. I won't say you should always use the create-a-worker-QObject-and-move-it-to-a-vanilla-QThread method, but in general, yes, that is the way to go. Especially if you plan to start using signals and slots.

Satmosc

@Andre: Thanks for information. yes , I guess there are situation that we may need to create new class from Qthread to add or reimplement functions.

dangelog

[quote author="Satmosc" date="1306746483"]
@peppe : in that example from Qt Sources I see that the thread::Start has been called from thread subclass and not the thread that object lives in.
[/quote]

What's the example you're talking about? And "from the thread subclass" doesn't mean much; as I said, adding a method which in turn calls start() and calling that method is fine (and I doubt start() is getting called from inside run()).

Satmosc

peppe: Check examples from QtSources Threading/queuedcustomtype
and in file "renderthread.cpp", Line 66:

@//![processing the image (start)]
void RenderThread::processImage(const QImage &image)
{
if (image.isNull())
return;

m_image = image;
m_abort = false;
start();

}@

dangelog

That processImage method gets called from the right thread (in the example, the GUI thread, which is where the RenderThread object is living), so it's safe to use that way.