QML and thread-safety
I'm writing an application with a QtQuick UI and the business logic in C++. My main window is instantiated by a QQmlApplicationEngine. I create some objects in C++ and pass them over to the QML engine as context properties. These objects are manipulated from both the QML side and the C++ side. My question is: Does the QQmlApplicationEngine run in its own thread and do I have to take care about thread-safety or does the whole application run in a single thread?
IMO there's no general answer to your question.
Using signals/slots you can share information across objects in multi-thread as well as in a single thread application.
The choice depends to your application requirements and constraints. Can you give more information?
I currently have an application that has both QML and C++ and I have no problems with thread-safety. That being said, I do not make any WorkerScript items in QML nor do I make another thread in C++. So in my case if I debug and stop in one of my C++ classes the application doesnt respond to input like a mouse or keyboard. (just trying to make this clear lol)
Does the QQmlApplicationEngine run in its own thread and do I have to take care about thread-safety or does the whole application run in a single thread?
The QQmlApplicationEngine runs code in the thread which constructed it. You don't have to worry about thread safety, unless you explicitly use WorkerScript in QML (or you spawn new threads in C++).
If you use any GUI components (i.e. if you use Qt Quick items), then your QQmlApplicationEngine must be constructed in the GUI thread, so that it runs code in the GUI thread.
The GUI thread is the thread which constructs QGuiApplication.
The QQmlApplicationEngine runs code in the thread which constructed it.
Thank you very much!