Locking code on slot connected to a QWebSocket

anphetamina

Hello,
I've setup a method that is being invoked when the binaryMessageReceived is emitted. I need to put the incoming message into a stack that will be consumed by two concurrent threads that will pop the messages as they are received. This is a typical producer-consumer scenario, but I'm having trouble understanding what happens if blocking code is put inside the slot. The access to the message queue is done exclusively, so what happens when new messages are received from the socket and new signals are emitted? Will they be lost or is the socket stuck inside the blocking code and not receive at all?
Maybe I'm misunderstanding something and I should try another approach.

Thank you.

SGaist

Hi,

It partly will depend on how the signal is connected. If direct connection then the caller will block. If queued, the events will accumulate and be consumed after the slot is done.

anphetamina

By "caller" do you mean the slot connected to the signal?
How do you queue events?

SGaist

@anphetamina said in Locking code on slot connected to a QWebSocket:

By "caller" do you mean the slot connected to the signal?

No, the objects that emits the signal

@anphetamina said in Locking code on slot connected to a QWebSocket:

How do you queue events?

In the case of signals and slots, you don't, Qt does that.

anphetamina

Let's say I have a SslEchoClient that encapsulate a QWebSocket and in its constructor this connections is made:

connect(&m_webSocket, &QWebSocket::connected, this, &SslEchoClient::onConnected);

...
void SslEchoClient::onConnected()
{
    connect(&m_webSocket, &QWebSocket::binaryMessageReceived,
            this, &SslEchoClient::onBinaryMessageReceived);
}
...
void SslEchoClient::onBinaryMessageReceived(QByteArray message)
{
    std::lock_guard lock(mutex) // this will block for a couple of ms
    // put message in stack for later consumption
}

Will SslEchoClient stop receiving messages from m_webSocket during the stop on the lock_guard?
What happens meanwhile SslEchoClient is waiting to acquire that mutex and new messages are received?
Will a long wait on that line makes the GUI unresponsive?

SGaist

If your mutex is locked long enough to start producing noticeable issues, then you should move your network related code in its own thread.

In any case, why do you need to use the producer/consumer paradigm in your case ?

anphetamina

Because I need to synchronize the access made on a document that is filled both with data coming from a QWebSocket and from user inputs locally. So my idea is to fill up a stack with data coming from my socket that is later used by separate threads that will synchronize the access to the document with the user inputs.