Quote Originally Posted by b-s-a View Post
Answer to this question should be very interesting.
Why? Because there are many devices. 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. The GUI simply provides a control and reporting interface. Each device needs to be service by non-blocking threads so all devices can be service without data loss. To do this you need signals and slots to occur WITHIN THE THREAD, not the GUI thread. Later, once the entire application runs at low volumes with dynamic OS scheduling, one can add the thread scheduling specific to the CPU vendor so the GUI can run on one CPU and the devices can be evenly allocated across other CPUs. First, you have to get each device to live within a thread. University research centers, labs, and many other organizations have been redeveloping this basic application design for decades. It isn't new. It has been done in Assembly, Fortran, C, and a host of other languages over the years. This particular instance chose to use Qt for a front end so an attempt is being made to use Qt for all of it instead of a hodge-podge.

Beginner:
>>P.S.: this is standard way to use QObject derived objects with signals and slots from other thread.

Thanks for the code, but it has little to do with the issue. I'm very aware of how to do threads and get signals across them. The problem is that signals are not working WITHIN a thread for the Serial stuff...unless that "thread" happens to be the main GUI thread.

Kuzulis:

>>This is not quite true. This class is an addon, but is not part of Qt! And most likely will not be as part of Qt, because it is the development of
custom developers, who do not have the time and resources to prepare and test the ad

Then qtproject should change the wording at the top of this page:
http://qt-project.org/wiki/QtSerialPort

"The QtSerialPort module is an add-on for the Qt5 library, providing a single interface for both hardware and virtual serial ports.
Note: Also added support and for library Qt4."

>>Where cheating? In BlockingMaster/BlockingSlave? O_o
Cheating, not testing, whichever. Because there is no example using signals and slots within threads, it generally means there also is no unit test for the same. Burning a thread with blocking IO may be fine student type work which only has to run for 5 minutes while the instructor looks at it, but it isn't the kind of programming which should be taught, especially for the library which created the signals and slots concept.

>>In addition to the Terminal example, there are other examples of the use of signals / slots without using Threads.
Look here: https://codereview.qt-project.org/#change,41981

Once again, not what I'm looking for. Signals and slots always work well within the GUI thread. Where testing and development have habbitually been an issue is making signals and slots live within a thread which is not the GUI thread. The classes for handling TCP/IP do this splendidly. Other classes from other developers for device interface also work perfectly in their own little thread. Currently, the serial port works well outbound only. The readyRead() signal gets lost. I asked for someone to provide a working example because if there was an actual unit test for this the code would be readily available. Instead, I got a bunch of flak and attempts to cut corners.

wysota:

Given a signal is getting lost, QSignalSpy is the next step when one is on their own debugging a signal problem. Hopefully it will reveal a method of jimmying the connect()/signal map to get around this bug/issue.

kuzulis:
>>Therefore, your conclusions are absolutely baseless and unconstructive.

I assume you were looking in the mirror when you wrote that.


Ok. So, obviously, there is no unit test code out there launching a ReadWrite serial port in its own thread which can be verified by connecting with Putty or some other terminal emulator. In short, I'm on my own tracking this bug down and fixing it.