Calls from QML to context property objects only in main thread?
-
Is there some kind of guarantee that all calls from QML to context property object's Q_PROPERTY and Q_INVOKABLE entry points only happen in the main (GUI) thread?
I was looking for documentation on this, but didn't find any.
Question is: Do I need to implement my functions reentrant or thread-safe?
-
Is there some kind of guarantee that all calls from QML to context property object's Q_PROPERTY and Q_INVOKABLE entry points only happen in the main (GUI) thread?
I was looking for documentation on this, but didn't find any.
Question is: Do I need to implement my functions reentrant or thread-safe?
@Asperamanca said in Calls from QML to context property objects only in main thread?:
Is there some kind of guarantee that all calls from QML to context property object's Q_PROPERTY and Q_INVOKABLE entry points only happen in the main (GUI) thread?
I don't think so.
Depending on backend used, it is possible that QML rendering uses multiple threads (cf. https://doc.qt.io/qt-5/qtquick-visualcanvas-scenegraph.html), so I suppose this will also be possible for calls from QML.If you are calling directly a function from QML (Q_INVOKABLE or slot) you should ensure it is thread safe, but Q_PROPERTY() should not be a problem, those will be called from event loop and therefore should be in the right thread.
EDIT: after reading documentation, I change my mind ;)
QML is executed by QQmlContext (https://doc.qt.io/qt-5/qqmlcontext.html), which runs in the thread in which it has been created, so if you create your QML context in main thread and also the C++ classes, it should not be required.
-
@Asperamanca said in Calls from QML to context property objects only in main thread?:
Is there some kind of guarantee that all calls from QML to context property object's Q_PROPERTY and Q_INVOKABLE entry points only happen in the main (GUI) thread?
I don't think so.
Depending on backend used, it is possible that QML rendering uses multiple threads (cf. https://doc.qt.io/qt-5/qtquick-visualcanvas-scenegraph.html), so I suppose this will also be possible for calls from QML.If you are calling directly a function from QML (Q_INVOKABLE or slot) you should ensure it is thread safe, but Q_PROPERTY() should not be a problem, those will be called from event loop and therefore should be in the right thread.
EDIT: after reading documentation, I change my mind ;)
QML is executed by QQmlContext (https://doc.qt.io/qt-5/qqmlcontext.html), which runs in the thread in which it has been created, so if you create your QML context in main thread and also the C++ classes, it should not be required.
@KroMignon
Thank you. I thought pretty much the same...while the rendering can happen in multiple threads, the data acquisition should be in one thread only.EDIT: And for QQuickImageProviders they explicitly say you need to be able to handle calls from different threads.
-
@KroMignon
Thank you. I thought pretty much the same...while the rendering can happen in multiple threads, the data acquisition should be in one thread only.EDIT: And for QQuickImageProviders they explicitly say you need to be able to handle calls from different threads.
@Asperamanca said in Calls from QML to context property objects only in main thread?:
EDIT: And for QQuickImageProviders they explicitly say you need to be able to handle calls from different threads.
Yes, this is normal because renderer could be multiple-threaded.
-
@Asperamanca said in Calls from QML to context property objects only in main thread?:
EDIT: And for QQuickImageProviders they explicitly say you need to be able to handle calls from different threads.
Yes, this is normal because renderer could be multiple-threaded.
@KroMignon said in Calls from QML to context property objects only in main thread?:
@Asperamanca said in Calls from QML to context property objects only in main thread?:
EDIT: And for QQuickImageProviders they explicitly say you need to be able to handle calls from different threads.
Yes, this is normal because renderer could be multiple-threaded.
My conclusion here is that they would note it elsewhere, if calls from multiple threads are to be expected.
