Are QTquick apps on android multi-threaded?
-
All Qt GUI apps have at minimum 2 threads: GUI thread and main thread. You are free to create more if you need to.
I'm building an object method that needs to block until a signal has been received.
Signals are processed only when application returns to the event loop. If you stop execution inside a function, it will prevent event loop from operating.
Since you are clearly in need of some asynchronous functionality, why not do this:
- stop responding to clicks
- return from your function immediately
- create a slot which will respond to your signal and unblock responding to clicks
Or something like that. I'm half-guessing how you want it to work so maybe I'm wrong.
-
I'm trying to integrate some C code that I inherited. The C code takes pointers to a couple of functions. One of them is a "write" function and immediately after calling "write", it calls the "read" function and expects a response (it takes some nominal amount of time for my object to receive the response, which comes from the signal).
How do I stop responding to clicks and what will that accomplish?
It just occurred to me that perhaps I can modify the C code so that I can return from the function immediately and the C code will retry until it gets what it wants. Although, I'm not sure that doing so will allow the application to return to the event loop... (EDIT: nevermind, I tried this and it didn't work)
-
Hm, in that case either rewrite the C code so that is fits into singals-slots paradigm of Qt, or run the C code in a separate thread. Both solutions should allow you to keep the UI responsive while getting your "wait for signal" functionality.
-
OK I used the QThread controller/worker example (http://doc.qt.io/qt-5/qthread.html) as a model. The worker provides the interface to my C-code and the controller receives the notification signal from my BLE service.
Since the worker can't handle incoming signals, I created a global data buffer (quint8 *) and a QMutex to pass data from controller to worker. It works like this:
- Worker locks the mutex
- Worker sends "write" signal to controller
- Controller receives response signal and copies response data into global data buffer
- Controller unlocks the mutex
- Worker sees unlocked mutex and reads data
Does this sound thread-safe? I ask because it works most of the time, but my worker occasionally gets stuck waiting for the mutex. I need to verify that it's not my controller dropping a BLE response notification.
EDIT: I just discovered that the interruption appears to be because this process suspends when my phone goes to sleep. Is there a way to allow it to continue while my phone is asleep? Alternatively, can it keep the phone from sleeping until it's done?
-
OK I used the QThread controller/worker example (http://doc.qt.io/qt-5/qthread.html) as a model. The worker provides the interface to my C-code and the controller receives the notification signal from my BLE service.
Since the worker can't handle incoming signals, I created a global data buffer (quint8 *) and a QMutex to pass data from controller to worker. It works like this:
- Worker locks the mutex
- Worker sends "write" signal to controller
- Controller receives response signal and copies response data into global data buffer
- Controller unlocks the mutex
- Worker sees unlocked mutex and reads data
Does this sound thread-safe? I ask because it works most of the time, but my worker occasionally gets stuck waiting for the mutex. I need to verify that it's not my controller dropping a BLE response notification.
EDIT: I just discovered that the interruption appears to be because this process suspends when my phone goes to sleep. Is there a way to allow it to continue while my phone is asleep? Alternatively, can it keep the phone from sleeping until it's done?
@kgregory said in Are QTquick apps on android multi-threaded?:
Since the worker can't handle incoming signals
Why? It's a QObject in another thread. It can receive signals just like any other QObject (they will use the queued connection).
Does this sound thread-safe?
You can verify that with thread sanitizer. I don't want to claim anything here, threads are a sensitive topic, I can easily claim something that is not true.
EDIT: I just discovered that the interruption appears to be because this process suspends when my phone goes to sleep. Is there a way to allow it to continue while my phone is asleep? Alternatively, can it keep the phone from sleeping until it's done?
That's planform-dependent, but can be done, sure.
-
Why? It's a QObject in another thread. It can receive signals just like any other QObject (they will use the queued connection).
Because it's running the C-code that is blocking, remember? This is the whole reason I had to spawn a separate thread.
That's planform-dependent, but can be done, sure.
awesome, thanks!
-
Why? It's a QObject in another thread. It can receive signals just like any other QObject (they will use the queued connection).
Because it's running the C-code that is blocking, remember? This is the whole reason I had to spawn a separate thread.
That's planform-dependent, but can be done, sure.
awesome, thanks!
@kgregory said in Are QTquick apps on android multi-threaded?:
Why? It's a QObject in another thread. It can receive signals just like any other QObject (they will use the queued connection).
Because it's running the C-code that is blocking, remember?
The signal will get into your thread's event loop queue and wait there until your C code finishes - then it will be processed. I think so, at least ;)
-
I have another question, is it possible that the QThread that I created in order to solve this problem may be recognized as a debugging feature by google play?
Google play isn't allowing me to upload my release build because it says it is "debuggable". See this thread for more detail: https://forum.qt.io/topic/84155/trouble-building-a-release-copy-for-android
-
I think you have not signed your .apk with the developer certificate, that might be the reason.
-
Hi,
Take a look at the Publish to GooglePlay chapter of Qt's documentation.
