How to prevent rendering from killing other periodic functions?

[crice]

Hello, we are fairly new to QT, and writing an embedded QT application (using QTQuick) that talks to a serial port (needs to send messages at a constant rate) and renders some complex, scrollable displays.

We have found that the user can use the display (for example, scrolling the chart) in a way that makes the serial messages stop for a bit. We believe that the scrolling/re-rendering is starving the timer that is driving the serial messages momentarily. Currently this is driven by a QTimer and a signal/slot connection.

We need to revise to ensure that the rendering of the display, no matter how complex, cannot prevent the sending of a serial message. What's the best way to do this in a QT application? We can make the display simpler, but this would simply reduce the chances of this -- if there is enough data to render this it seems this is always possible with our current approach -- we want this to not be possible.

I can imagine answers ranging from setting priority flags (if any) in the QT framework, to re-sourcing our serial comm from the QT Timer to something more deterministic, to making our application multithreaded (I hope it doesn't get this drastic, but we will do this if it's the only way to ensure serial cant be interrupted).

Any thoughts from experienced QT folks are very appreciated.

[high_flyer]

to making our application multithreaded (I hope it doesn't get this drastic, but we will do this if it's the only way to ensure serial cant be interrupted).

Why drastic?
Sounds like a classical case for threading.

[crice]

To be honest I would've thought a QTimer put it on a different thread for you.

It would be drastic because the serial port is part of a large "back end" component, and up till now we've freely been calling back end functions from the UI. I expect we'll have to write a LOT of thread synchronization between the UI and the back end. Unless Qt makes it trivial? Never done this before...

[high_flyer]

To be honest I would've thought a QTimer put it on a different thread for you.
No. All it does is count time, and calls the connected slot (in your case in the main gui thread) when the timeout occurs.

It would be drastic because the serial port is part of a large "back end" component, and up till now we've freely been calling back end functions from the UI. I expect we'll have to write a LOT of thread synchronization between the UI and the back end. Unless Qt makes it trivial? Never done this before...
I am not sure what the one has to do with the other, and why you will have to write any synchronization code at all.
Put the reading and writing to/from the serial port in its own thread, what's the big deal?
Read about QThreadPool and QRunnable.
Just make sure you mutex your thread shared data (what you write to and from the serial port).