Quote Originally Posted by RolandHughes View Post
Why? Because there are many devices.
So?

You don't burn a thread using blocking waitFor calls when you have many, potentially many dozens, of devices communicating via serial, tcp/ip, digital, and other means.
You don't burn a thread when using signals and slots. Nobody says you should use waitFor*.

Each device needs to be service by non-blocking threads so all devices can be service without data loss.
What data loss? What are you talking about? Non-blocking threads? So if you want to handle say... 20 devices, you'd need 20 "non-blocking threads", thus you'd need at least 21 concurrent threads (assuming there are no other processes running in the system) thus at least 21 cores or processing units in your machine. Otherwise those threads will block because they have to share a limited number of processors.

To do this you need signals and slots to occur WITHIN THE THREAD, not the GUI thread.
No. Especially if, as you said yourself, GUI provides only an interface for controlling and reporting results. Unless you are running a really old machine (like 10 years old), a single thread will happily handle the UI and serial input.

Given a signal is getting lost
Signals can't be "getting lost". They are not socks falling under your washing machine. Qt's signal handling code is deterministic.