Qt-interest Archive, April 2008
verifying some assumption about queued signals when the event loop isn't running yet...
Message 1 in thread
hi,
it is common that app.exec() is ran as return value of the main function.
eg. at the very end of the application. Imagine before that i already create
threads and they start running, and in those threads threre are objects that
send signals to objects in the main thread. The main thread where we haven't
yet entered exec()...
Can I count on the fact that the signals will be kept and delivered when
exec starts, or might they get lost ???
cheers.
naja
Message 2 in thread
I would have the threads available but not started until the main thread
is available to receive them.
Its quite coimmon to have the activation slot, ie the slot you are using
to add to the threads data queue, do something like
If ( !isRunning() )
Start()
Scott
From: Naja Melan [mailto:najamelan@xxxxxxxxx]
Sent: Tuesday, April 08, 2008 4:25 AM
To: qt-interest@xxxxxxxxxxxxx
Subject: verifying some assumption about queued signals when the event
loop isn't running yet...
hi,
it is common that app.exec() is ran as return value of the main
function. eg. at the very end of the application. Imagine before that i
already create threads and they start running, and in those threads
threre are objects that send signals to objects in the main thread. The
main thread where we haven't yet entered exec()...
Can I count on the fact that the signals will be kept and delivered when
exec starts, or might they get lost ???
cheers.
naja
Message 3 in thread
Scott,
That idea sounds interesting, but how would a slot in the thread get
executed if that thread's exec loop wasn't already running? Can you
post a more complete example?
________________________________
From: Scott Aron Bloom [mailto:Scott.Bloom@xxxxxxxxxxxx]
Sent: Tuesday, April 08, 2008 11:16 AM
To: qt-interest@xxxxxxxxxxxxx
Subject: RE: verifying some assumption about queued signals when the
event loop isn't running yet...
I would have the threads available but not started until the main thread
is available to receive them.
Its quite coimmon to have the activation slot, ie the slot you are using
to add to the threads data queue, do something like
If ( !isRunning() )
Start()
Scott
From: Naja Melan [mailto:najamelan@xxxxxxxxx]
Sent: Tuesday, April 08, 2008 4:25 AM
To: qt-interest@xxxxxxxxxxxxx
Subject: verifying some assumption about queued signals when the event
loop isn't running yet...
hi,
it is common that app.exec() is ran as return value of the main
function. eg. at the very end of the application. Imagine before that i
already create threads and they start running, and in those threads
threre are objects that send signals to objects in the main thread. The
main thread where we haven't yet entered exec()...
Can I count on the fact that the signals will be kept and delivered when
exec starts, or might they get lost ???
cheers.
naja
Message 4 in thread
The slot is not run from the Qthreads thread, but the main apps
thread....
Remember, unless you call moveToThread on the QThread itself, the
allocating thread is the owner thread for the QThread object.
So when you connect to the qthread, it is NOT a queud connection, it's a
direct connection.
A non -tested (ie, typing it right here) so don't rely on syntax..
Thread::Thread() :
m_stopped( false ) // defined volatile in the class definition
{
}
Thread::slotAddToQueue( const QString & string ) // assumes a list of
strings is whats worked on
{
If ( !isRunning() )
Start();
m_Mutex.lock();
m_list.push_back( string );
m_mutex.unlock();
}
Thread::run()
{
While ( !m_stopped )
{
if ( fStopped )
return;
m_Mutex.lock()
if ( !m_list.isEmpty() )
{
QString current = m_list.pop_front();
workOnString( current );
}
M_mutex.unlock();
}
}
Of course, you will have to write a much better run() so that the loop
is paused when the list is empty... But this is how I tend to implement
my list worker threads.
Scott
From: Joaquin Luna [mailto:Joaquin.Luna@xxxxxxxx]
Sent: Tuesday, April 08, 2008 8:37 AM
To: qt-interest@xxxxxxxxxxxxx
Subject: RE: verifying some assumption about queued signals when the
event loop isn't running yet...
Scott,
That idea sounds interesting, but how would a slot in the thread get
executed if that thread's exec loop wasn't already running? Can you
post a more complete example?
________________________________
From: Scott Aron Bloom [mailto:Scott.Bloom@xxxxxxxxxxxx]
Sent: Tuesday, April 08, 2008 11:16 AM
To: qt-interest@xxxxxxxxxxxxx
Subject: RE: verifying some assumption about queued signals when the
event loop isn't running yet...
I would have the threads available but not started until the main thread
is available to receive them.
Its quite coimmon to have the activation slot, ie the slot you are using
to add to the threads data queue, do something like
If ( !isRunning() )
Start()
Scott
From: Naja Melan [mailto:najamelan@xxxxxxxxx]
Sent: Tuesday, April 08, 2008 4:25 AM
To: qt-interest@xxxxxxxxxxxxx
Subject: verifying some assumption about queued signals when the event
loop isn't running yet...
hi,
it is common that app.exec() is ran as return value of the main
function. eg. at the very end of the application. Imagine before that i
already create threads and they start running, and in those threads
threre are objects that send signals to objects in the main thread. The
main thread where we haven't yet entered exec()...
Can I count on the fact that the signals will be kept and delivered when
exec starts, or might they get lost ???
cheers.
naja
Message 5 in thread
This is easy to verify by writing a short example. But it also makes
since that it would work if you think about how qt manages queued
connections. Each time you create a thread (including the main thread)
one of the data structures that Qt creates is a queue to hold the
incoming signals. If this queue wasn't created, there would be no way
to connect a signal to a slot in another thread. The signal would not
know where to register itself. Once a thread gets to its exec loop it
starts to check that thread, which may already contain a few queued
signals.
Here is a program to verify this, note that if the destroyed signal was
lost, you would never see the button.
#include <QApplication>
#include <QObject>
#include <QThread>
#include <QPushButton>
class myThread : public QThread
{
public:
myThread (QPushButton * button)
:b(button)
{}
void run ()
{
QObject * x = new QObject();
QObject::connect(x, SIGNAL(destroyed()), b, SLOT(show()));
delete x;
}
private:
QPushButton * b;
};
int main(int argc, char *argv[])
{
QApplication app(argc, argv);
QPushButton b;
myThread t(&b);
// Start the thread
t.start();
sleep(5);
return app.exec();
}
From: Naja Melan [mailto:najamelan@xxxxxxxxx]
Sent: Tuesday, April 08, 2008 7:25 AM
To: qt-interest@xxxxxxxxxxxxx
Subject: verifying some assumption about queued signals when the event
loop isn't running yet...
hi,
it is common that app.exec() is ran as return value of the main
function. eg. at the very end of the application. Imagine before that i
already create threads and they start running, and in those threads
threre are objects that send signals to objects in the main thread. The
main thread where we haven't yet entered exec()...
Can I count on the fact that the signals will be kept and delivered when
exec starts, or might they get lost ???
cheers.
naja
