Signals, Threads and the Event Queue

[DalePennington]

Folks,

We have an app acting strangely, so we are looking at all possible avenues that might be the cause.
With regard to the question here, we have an object, created on the main thread, that registers a call back with a third party communications library that invokes the callback on its own thread. We take the incoming message, put it in a QQueue (protected by a QMutex), and emit a signal. The slot the signal is associated with is in the same object, but should be being called in the main Qt thread.
The questions are several. First, is the signal passed to the main thread via the Qt Event Mechanism ? I known the documentation says that QueuedConnections process when the receiving threads Event Dispatcher runs, but I am trying to confirm details. I am also assuming from the documentation that the method is thread-safe.
Second, with regards to the queued events, is there a limit to the Qt Event Queue size ? If so, what happens when it overflows ? Finally is there a way to see how many pending events their are ?
I doubt this is what is causing the issue, but we are trying to eliminate all possible issues.

Thanks,
Dale Pennington

[SGaist]

Hi,

Why does the slot need to be called in main thread ? Is it changing GUI elements ? How exactly to you emit your signal ?

The slot shall be called in whichever thread the target object has affinity with.

For queued connections, yes the event system is used to pass from on thread to another. More details here.

I don't know whether there's an upper limit on the event queue but if you manage to overload it, then you may have a performance hit somewhere you have to find, a design issue or a need for a more powerful machine. The last one is the less likely usually.

[DalePennington]

The slot is in the main thread because it does change graphical elements.

Basically we have a callback function that looks like this

void CommClass::Callback(Data data)
{
    dataMutex.lock();
    dataQueue.enqueue(data);
   dataMutex.unlock();
   emit DataReceived();
}

DataRecieved is tied to slot HandleData

void CommClass::HandleData
{
    while(1)
    {
        dataMutex.lock();
        if( dataQueue.empty() )
        {
            dataMutex.unlock();
            return;
        }

        Data localData = dataQueue.dequeue();
        dataMutex.unlock();

        //  Use data here to update display elements.
    }
}

We are getting a backup to processing the data due to other GUI interfaces creating a backlog, so boss was worried about possibly overflowing the Event Queue and that being a possible issue.

Thanks for the time,
Dale Pennington

[Christian Ehrlicher]

@DalePennington said in Signals, Threads and the Event Queue:

while(1)

This is running in the main thread? How do you break this loop?

[JonB]

@Christian-Ehrlicher said in Signals, Threads and the Event Queue:

How do you break this loop?

Well, on his first 5 lines. No data => unlock and return?
Else he seems to process whole queue from slot.

[Christian Ehrlicher]

@JonB said in Signals, Threads and the Event Queue:

Well, on his first 5 lines. No data => unlock and return?

Correct, strange logic though :)