Do Non GUI threads again start executing( signal/slot events ),after they come to rest ?

blue_sky

suppose, a non GUI thread finished executing its codes. after which it gets an event(SIGNAL) to execute a slot of an Object, Which was created inside that Non GUI thread.
Now, Who will perform this task?The NON-GUI thread/ the main GUI thread, which is still alive?

JKSH

Hi,

The thread needs a running event loop to process signals. If your event loop has stopped, then the slot of the object that was created inside the non-GUI thread will never get executed.

blue_sky

So its all depends on event loop. But What happened generally for a secondary thread. IS the event loop is destroyed, or exists till the end f the application?
[quote author="JKSH" date="1385208687"]Hi,

The thread needs a running event loop to process signals. If your event loop has stopped, then the slot of the object that was created inside the non-GUI thread will never get executed.[/quote]

MuldeR

With a direct connection, the Slot will be executed by the thread who has emitted the Signal. In this case, the emit() will block until the Slot has been executed. If, instead, a queued connection is used, the emit() will simply put the Signal into the queue of the thread to which the receiver object belongs to. So the Slot will be called, eventually, by the thread to which the object belongs. This requires the thread to be running an event loop. If that thread does not run an event loop, the Slot will not be executed. Also, Signals that are received while the thread does not run an event loop are not lost. They will be processed as soon as an event loop is created and run in the thread.

BTW: Running an event loop does not require GUI components. Non-GUI threads may be running an event loop just as well...

JKSH

[quote author="blue_sky" date="1385233583"]But What happened generally for a secondary thread. IS the event loop is destroyed, or exists till the end f the application?[/quote]The event loop in the main thread will keep running until you quit the application by calling QCoreApplication::quit() (this might be called automatically if you close all your windows).

A secondary thread's event loop will keep running until you stop the thread by calling QThread::quit() (this is not called automatically).

blue_sky

what do you ean by- Non GUI threads may run event loop?What decides running of event loop for non gui thread?
A secondary thread comes to rest does not mean that- event loop of that thread is destroyed?Correct if I am wrong?
[quote author="MuldeR" date="1385237250"]With a direct connection, the Slot will be executed by the thread who has emitted the Signal. In this case, the emit() will block until the Slot has been executed. If, instead, a queued connection is used, the emit() will simply put the Signal into the queue of the thread to which the receiver object belongs to. So the Slot will be called, eventually, by the thread to which the object belongs. This requires the thread to be running an event loop. If that thread does not run an event loop, the Slot will not be executed. Also, Signals that are received while the thread does not run an event loop are not lost. They will be processed as soon as an event loop is created and run in the thread.

BTW: Running an event loop does not require GUI components. Non-GUI threads may be running an event loop just as well...[/quote]

blue_sky

Thank you. now its clear that- A threads event loop is still present , whether thread is running or at rest.
[quote author="JKSH" date="1385256647"][quote author="blue_sky" date="1385233583"]But What happened generally for a secondary thread. IS the event loop is destroyed, or exists till the end f the application?[/quote]The event loop in the main thread will keep running until you quit the application by calling QCoreApplication::quit() (this might be called automatically if you close all your windows).

A secondary thread's event loop will keep running until you stop the thread by calling QThread::quit() (this is not called automatically).[/quote]

MuldeR

[quote author="blue_sky" date="1385290197"]what do you ean by- Non GUI threads may run event loop?What decides running of event loop for non gui thread?[/quote]

You do!

By creating a QEventLoop object in that thread object an calling exec().

Usually in the "main" thread you will not explicitly create a QEventLoop and just use QApplication::exec(). But it doesn't mean you couldn't create your own additional QEventLoop objects in the main thread as well. For example, to wait for something in a "synchronous" way (and still have to GUI responsive) you can do something like that, even in the "main" thread:

@MyTask someTask;
QEventLoop myLoop;

connect(&someTask, SIGNAL(done()), &myLoop, SLOT(quit()));
someTask->start();

qDebug("Task started, begin event processing...");
myLoop->exec();
qDebug("Task completed.");@

_

[quote author="blue_sky" date="1385290197"]A secondary thread comes to rest does not mean that- event loop of that thread is destroyed?Correct if I am wrong?[/quote]

Not sure what "comes to rest" is supposed to mean?

Anyway, to have the thread run an event loop you would do the following - and that's exactly what the default implementation of QThread::run() does:
@QEventLoop myLoop;
myLoop.exe()@

That loop is destroyed when exec() returns and "myLoop" goes out of scope, that's simple C++ and there's no secret Qt magic behind it ;-)

blue_sky

Thank you SIr. So all secondary threads created in main thread by default having their own event loops.When secondary thread finishes executing its codes,does event loop of that thread is destroyed automatically?
[quote author="MuldeR" date="1385299107"][quote author="blue_sky" date="1385290197"]what do you ean by- Non GUI threads may run event loop?What decides running of event loop for non gui thread?[/quote]

You do!

By creating a QEventLoop object in that thread object an calling exec().

Usually in the "main" thread you will not explicitly create a QEventLoop and just use QApplication::exec(). But it doesn't mean you couldn't create your own additional QEventLoop objects in the main thread as well. For example, to wait for something in a "synchronous" way (and still have to GUI responsive) you can do something like that, even in the "main" thread:

@MyTask someTask;
QEventLoop myLoop;

connect(&someTask, SIGNAL(done()), &myLoop, SLOT(quit()));
someTask->start();

qDebug("Task started, begin event processing...");
myLoop->exec();
qDebug("Task completed.");@

_

[quote author="blue_sky" date="1385290197"]A secondary thread comes to rest does not mean that- event loop of that thread is destroyed?Correct if I am wrong?[/quote]

Not sure what "comes to rest" is supposed to mean?

Anyway, to have the thread run an event loop you would do the following - and that's exactly what the default implementation of QThread::run() does:
@QEventLoop myLoop;
myLoop.exe()@

That loop is destroyed when exec() returns and "myLoop" goes out of scope, that's simple C++ and there's no secret Qt magic behind it ;-)[/quote]

[quote author="MuldeR" date="1385299107"][quote author="blue_sky" date="1385290197"]what do you ean by- Non GUI threads may run event loop?What decides running of event loop for non gui thread?[/quote]

You do!

By creating a QEventLoop object in that thread object an calling exec().

Usually in the "main" thread you will not explicitly create a QEventLoop and just use QApplication::exec(). But it doesn't mean you couldn't create your own additional QEventLoop objects in the main thread as well. For example, to wait for something in a "synchronous" way (and still have to GUI responsive) you can do something like that, even in the "main" thread:

@MyTask someTask;
QEventLoop myLoop;

connect(&someTask, SIGNAL(done()), &myLoop, SLOT(quit()));
someTask->start();

qDebug("Task started, begin event processing...");
myLoop->exec();
qDebug("Task completed.");@

_

[quote author="blue_sky" date="1385290197"]A secondary thread comes to rest does not mean that- event loop of that thread is destroyed?Correct if I am wrong?[/quote]

Not sure what "comes to rest" is supposed to mean?

Anyway, to have the thread run an event loop you would do the following - and that's exactly what the default implementation of QThread::run() does:
@QEventLoop myLoop;
myLoop.exe()@

That loop is destroyed when exec() returns and "myLoop" goes out of scope, that's simple C++ and there's no secret Qt magic behind it ;-)[/quote]

MuldeR

[quote author="blue_sky" date="1385313377"]Thank you SIr. So all secondary threads created in main thread by default having their own event loops.When secondary thread finishes executing its codes,does event loop of that thread is destroyed automatically?[/quote]

"Secondary" threads, as you call them, do not run an event loop by default. A thread won't be running an event loop, unless one is created and run (see examble above). It's just that the default implementation of QThread::run() happens to create and run an event loop. So if you create/start an instance of the original QThread, it will be running an event loop, indeed. But if you sublcass QThread and overwrite run(), then it will not be running an event loop! - unless you create and run the event loop yourself.

Furthermore, once QEventLoop::exec() has been called, the event loop will continue to run for an arbitrary amount of time - until it exists. This can happen, for example, when the quit() slot or the exit() function of the individual event loop is invoked. It also happens when QThread::quit() is called - given that the thread is actually running an event loop.

After an event loop exists from it's exec() method, it stops processing events - for now. But the event loop object continues to exists and exec() can be called again! The event loop is not "destroyed" until the QEventLoop object is destroyed, e.g. because it goes out of scope - and that's simple C++ logic!

@MyThread::run(void)
{
//No event loop running yet!
DoInitializationStuff();

//Let's start event processing at this point :-&#41;
QEventLoop myLoop;
myLoop.exec(&#41;;

//Event processing has stopped
//But 'myLoop' will not be destroyed, until it goes out of scope!
DoFinalizationStuff(&#41;;

}
@