The Qt example seems affected by race conditions

[lultimouomo]

Hi,

I honestly just glanced the code, but the Qt example seems to invoking UI methods from the socket callbacks, which (I guess) are executed from an ASIO thread, not the main Qt one.

https://github.com/socketio/socket.io-client-cpp/blob/9663ca3c64a79c5bbd9f403fddd8a82e70f6f589/examples/QT/SioChatDemo/mainwindow.cpp#L41-43 should use Qt::QueuedConnection, otherwise the connected slots will be executed in line in the current thread.

[melode11]

Thanks for reporting, I'm just start to use QT for this demo, what you guess about the thread is true, and the purpose I used Signals/Slots is to invoke the UI operations in UI thread. It seems I choose a wrong way? I'll try to verify.

[melode11]

Hi, @lultimouomo I've test by set breaking point at AddListItem() (which is triggered by signal from asio thread) and OnMessageReturn()(which is triggered by return key, absolutely in UI thread)
I found AddListItem() executes in the same thread with OnMessageReturn(),
which means the signals/slots mechanism WILL post the invocation to the UI thread.

[lultimouomo]

You're right, I thought the connection type (i.e. whether to execute the slot in line or post an event on the loop) was chosen at connection time, according to the thread affinity of the sender and the receiver.
http://doc.qt.io/qt-5/qt.html#ConnectionType-enum states instead that it's chosen when the signal is actually emitted, so the code is OK.
I would consider indicating Qt::QueuedConnection explicitely anyway, since it makes the code intention more clear.

[melode11]

Hi, @lultimouomo I think indicating Qt::QueuedConnection explicitly is not the good choice, AutoConnection is better than QueuedConnection in this case because If you did signal AddListItem in UI thread somewhere, inline execution is preferred, so you can indicating Qt::AutoConnection explicitly instead.