Can you discover Qt::ConnectionType after a connect(Qt::AutoConnection)?
-
After a (successful)
QMetaObject::Connection connection = connect(..., Qt::AutoConnection);at runtime, can you discover which
Qt::ConnectionTypewas chosen by Qt? I thought it would be a member of the returnedQMetaObject::Connectionbut seemingly not? Qt does resolve/pick forQt::AutoConnectionduring theconnect()statement, doesn't it?I do not want to pass an explicit
Qt::ConnectionTypeas I want the default behaviour onQt::AutoConnection, e.g. if the objects are in different threads I need Qt to pick the queued type. But I wish to have the option to follow it withQ_ASSERT(connection.type == Qt::DirectConnection), as if it is not direct I need to reconsider the logic. -
After a (successful)
QMetaObject::Connection connection = connect(..., Qt::AutoConnection);at runtime, can you discover which
Qt::ConnectionTypewas chosen by Qt? I thought it would be a member of the returnedQMetaObject::Connectionbut seemingly not? Qt does resolve/pick forQt::AutoConnectionduring theconnect()statement, doesn't it?I do not want to pass an explicit
Qt::ConnectionTypeas I want the default behaviour onQt::AutoConnection, e.g. if the objects are in different threads I need Qt to pick the queued type. But I wish to have the option to follow it withQ_ASSERT(connection.type == Qt::DirectConnection), as if it is not direct I need to reconsider the logic.@JonB said in Can you discover Qt::ConnectionType after a connect(Qt::AutoConnection)?:
can you discover which Qt::ConnectionType was chosen by Qt
No since it's selected during the execution of the slot and therefore might change depending on where the two objects live.
Qt Online Installer direct download: https://download.qt.io/official_releases/online_installers/
Visit the Qt Academy at https://academy.qt.io/catalog -
@JonB said in Can you discover Qt::ConnectionType after a connect(Qt::AutoConnection)?:
can you discover which Qt::ConnectionType was chosen by Qt
No since it's selected during the execution of the slot and therefore might change depending on where the two objects live.
@Christian-Ehrlicher
Ah. So, just as an example, you could have aconnect(signalObject, ..., slotObject, ..., Qt::AutoConnection);where when the
connect()statement is executed to make the connection the two objects live in the same thread but then you move one of them to another thread, and the connection would change from direct to queued effectively at the time the signal is emitted, right?OK. This means then that the overhead/implementation is a bit "heavier" at signal emit time than I had thought. For example, when docs etc. say "(with AutoConnection and single thread) an
emit signal()gives a direct call to slot(s)", there is actually a runtime check in the signal function call each time it is emitted to determine whether signal object and slot object are in same thread? -
It's a simply QObject::thread() == receiver->thread(), yes. See https://code.qt.io/cgit/qt/qtbase.git/tree/src/corelib/kernel/qobject.cpp#n4315
-
J JonB has marked this topic as solved
-
It's a simply QObject::thread() == receiver->thread(), yes. See https://code.qt.io/cgit/qt/qtbase.git/tree/src/corelib/kernel/qobject.cpp#n4315
@Christian-Ehrlicher But isn't checking the thread at least slightly expensive? Or does the QObject just store an "integer"? Otherwise couldn't the proper connection type be automatically set when calling
connectandmoveToThreadcould do the heavy lifting just a single time to update the connection type of all connections (that have been set up with AutoConnection). We could at least save some conditionals (and quickly looking at the code some atomics).
