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

[BRM]

Signals and Slots only work with threads that have Event Loops, which your object A seems to lack.
Now, you could always add in the event loop processing (there's several examples in the archives I think) or make A be an event loop with a recurring event - basically, setup object A as:

class ObjectA : public QThread()
{
..
ObjectA();
~ObjectA();
void run();
protected slots:
void readFile();
...
public slots:
void pauseRead(bool _pause);
...
protected:
bool pauseReading;
};


void ObjectA::run()
    {
    QTimer::singleShot(10,this,SLOT(readFile()));
    exec();
    }
void ObjectA::readFile()
    {
    if (pauseReading == false)
        {
        // do your normal read stuff here
        }
    ...
    QTimer::singleShot(1,this,SLOT(readFile()));
    }
void ObjectA::pauseRead(bool _pause)
    {
    pauseReading = _pause;
    }

That should effectively do it; though you may need another object layer in the thread. I usually do that - having a QThread derived class that allocates a class that has all the work the thread is suppose to do, and then the QThread derived class is just a signal relay class that ensures the thread boundary is properly crossed.

Ben


________________________________
From: Preet <preet.desai at gmail.com>
To: qt-interest at trolltech.com
Sent: Sun, December 13, 2009 8:25:36 PM
Subject: Re: [Qt-interest] Queued/DirectConnections for signals across threads

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::DirectConnection 1 When emitted, the signal is immediately delivered to the slot. 
Qt::QueuedConnection 2 When 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/5e0836e7/attachment.html