So?
You don't burn a thread when using signals and slots. Nobody says you should use waitFor*.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.
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.Each device needs to be service by non-blocking threads so all devices can be service without data loss.
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.To do this you need signals and slots to occur WITHIN THE THREAD, not the GUI thread.
Signals can't be "getting lost". They are not socks falling under your washing machine. Qt's signal handling code is deterministic.Given a signal is getting lost
Bookmarks