[Qt-interest] Queued/DirectConnections for signals across threads

[Scott Aron Bloom]

I would expect object b's someFunction to emit the signals and return
immediate, but the signal stop to have no effect because object a gets
locked into an infinite loop that is not accessing the event loop.

 

However, without seeing more code, im guessing, since I have no idea
what object A looks like

 

Scott

 

From: qt-interest-bounces at trolltech.com
[mailto:qt-interest-bounces at trolltech.com] On Behalf Of Preet
Sent: Sunday, December 13, 2009 11:07 AM
To: qt-interest at trolltech.com
Subject: [Qt-interest] Queued/DirectConnections for signals across
threads

 

Hey all,

I have two threads, each with their own object. Both threads are running
exec() event loops so signals and slots will be handled by those two
threads. I have this one slot (slot Run) in one the objects (object A)
that has a while(someCondition) loop. This same object has another slot
(slot Stop) that will set 'someCondition' to false.

By default, any connections I make between the two objects will be of
the type QueuedConnection. My other object (object B) has signals to
invoke the Run and Stop slots. If I do something like:

ObjectB::someFunction()
{
   someCondition = true;
   emit signalRun;   // queued connection
   emit signalStop;   // queued connection
   std::cerr << "someFunction done" << std::endl;
}

I expect someFunction to emit two signals, then return immediately. I
expect object A's thread, if its not doing anything else, to be stuck in
an infinite while loop.

So if I do the following:

ObjectB::someFunction()
{
   someCondition = true;
   emit signalRun;   // queued connection
   emit signalStop;   // direct connection
   std::cerr << "someFunction done" << std::endl;
}

What is the resulting program flow? 


Regards,

-Preet

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.qt-project.org/pipermail/qt-interest-old/attachments/20091213/6b3c74c9/attachment.html