Solved Are QTquick apps on android multi-threaded?
-
I'm building an object method that needs to block until a signal has been received. I decided to use QMutex to accomplish this. I'm having some trouble with it though, and I'm wondering if waiting on the mutex might be causing me to miss the signal due to the app being single-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?
-
@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!
-
@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.
-
How do you do that?
-
I opted out of google play app signing, if that's what you mean.
-
Hi,
Take a look at the Publish to GooglePlay chapter of Qt's documentation.
-
I should have known to look around for a document on this... thanks!