The Qt example seems affected by race conditions about socket.io-client-cpp

[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.