When exactly textMessageReceived is emitted

Pippin

Hi, quick question.

A QWebSocket doesn't actually emit the textMessageReceived(const QString&) signal the moment it received a new message, but a few milliseconds later, when the main loop has all connected sockets check for new messages, right?

If that's what I said, then I don't have anything to do.

But if Qt is designed to interrupt itself whenever a socket gets a new message, then I'll have to implement a queue system.

Christian Ehrlicher

What do you mean with 'interrupt itself'?
When qt receveives a new message from the os that there is something to do then it is done. If you block the eventloop then the message can't be handled until the event loop is running again.

Pippin

Let's suppose I connect the clicked signal of a QPushButton to a slot. I click on it, and for some reason, the slot takes a very long time to finish (let's say there's an infinite loop or whatever). During that time, is it possible for QWebSockets to emit the textMessageReceived signal?

I'm just trying to understand how many threads are used in total for Qt to work properly. If I understood you correctly, then the textMessageReceived signal(s) would not be emitted until the time-consuming slot has finished its job.

Christian Ehrlicher

I already answered it: "If you block the eventloop then the message can't be handled until the event loop is running again."
So no matter where the signal is coming from (OS or different thread) it is not handled until the eventloop is running again.

Pippin

Thank you @Christian-Ehrlicher, it's clear to me now.