You don't want the user interface to freeze while waiting for the response. Mutexes won't help you, and blocking execution is the wrong approach in UI programming. TextMessageReceived will be emitted in between any other events (user input among them), in a sequence managed by the event loop, but never in a parallel, multithreaded way.Īs you already noted, QWebSocket doesn't provide a mechanism to track which response belongs to which request. So unless you work with threads in your own code, there are only very very few cases where one would have use for a QMutex or other explicit thread synchronization (custom painting of QtQuick items is the only one coming to my mind). Qt's I/O/networking-related classes including QWebSocket are asynchronous to avoid blocking the main thread, but never expose any multithreading they might use internally to the user of the API. So what should I do to prevent race conditions? (and can I make this even simpler so I don't need any "in-between" variables like both response and the_response, or the event loop?)ĮDIT I saw this question (and more importantly this answer) linked in the sidebar, and that has got me thinking that I can just use a lambda instead of this whole setup, but perhaps keeping the mutex as a simple but relatively expensive way to prevent cross-talk between responses and requests. Will the QString response be "filled" immediately after the call to sendTextMessage? I'd think not, but that implies all the QWebSocket machinery is async, and I can't find that explicitly in its documentation. continue processing "response" immediately Or if a much simpler setup would do (no mutex nor event loop): // initialization after QWebSocket is connectedĬonnect(&socket, &QWebSocket::textMessageReceived, this, &client::record_response) // store the response in a member QString What I'm asking is if I need this: // somewhere in initialization code, I have it in a slot connected to the QWebSocket's "connected" signalĬonnect(&socket, &QWebSocket::textMessageReceived, this, &client::record_response) // store the response in a member QString called "response"Ĭonnect(&socket, &QWebSocket::textMessageReceived, &wait_for_it, &QEventLoop::quit) Is there any race condition between the sendTextMessage and textMessageReceived in the sense that sending two messages almost at the same time could trigger a mixup of responses? Imagine this: there are several buttons that trigger a message sent over the QWebSocket, they receive and process the response, and then display the result.
I'm trying to send and receive messages over a QWebSocket, but am uncertain as to how safe this all is in a "user pressing all the buttons at the same time" scenario.
0 kommentar(er)
