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

[Preet]

Object A is reading in a file line by line until eof(). I want to be able to
'pause' this process briefly and resume it again with a control flag. The
object also does other stuff which requires it to have an event loop.

I'm not understanding the difference between how queued connections and
direct connections behave in this context. The Qt docs state:

Qt::DirectConnection1When emitted, the signal is immediately delivered to
the slot.Qt::QueuedConnection2When emitted, the signal is queued until the
event loop is able to deliver it to the slot.
So shouldn't a directly connected signal just force Object A to jump from
whatever line it is executing to the beginning of the respective slot?

Here's Object A reading a file (no Qt, just a simple while loop)


void ObjectA::RunFileInput
while(1)
{
_axis->_lockStateData.lock();
if (!(_axis->_fileInputRunning)) { break; }
_axis->_lockStateData.unlock();
 _axis->playbackFile >> fileRow.data_;
if (_axis->playbackFile.eof()) { break; }
 usleep(50*1000);
 // update buffer
_axis->_lockBuffer.lock();
_axis->_inputBuffer.push_back(fileRow);
_axis->_lockBuffer.unlock();
}


Regards,

-Preet

On Sun, Dec 13, 2009 at 2:11 PM, Scott Aron Bloom
<Scott.Bloom at sabgroup.com>wrote:

>  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
>
> _______________________________________________
> Qt-interest mailing list
> Qt-interest at trolltech.com
> http://lists.trolltech.com/mailman/listinfo/qt-interest
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.qt-project.org/pipermail/qt-interest-old/attachments/20091213/525985cf/attachment.html