Need Qt SerialPort class example using signals and slots WITHIN A THREAD

[RolandHughes]

I'm currently trying to use the SerialPort class which will be included as part of Qt 5 according to the Web site. Using it with 4.x on Ubuntu Linux. The examples are all kind of worthless. The documentation says the SerialPort class is thread safe, yet, SerialPort.h deliberately disables a copy constructor which makes it very difficult to do signalling. I have found many cheating examples which call waitForReadyRead() instead of doing it right.

Don't care about other libraries or other tools.

Looking actual compiling example of SerialPort class using signals and slots within a thread which is NOT the GUI thread.

Thanks,

[wysota]

The documentation says the SerialPort class is thread safe, yet, SerialPort.h deliberately disables a copy constructor

That's what each QObject-derived class does. It's perfectly normal.

which makes it very difficult to do signalling.

I don't see how signalling is related to copying.

[RolandHughes]

That's what each QObject-derived class does. It's perfectly normal.


I don't see how signalling is related to copying.

http://doc.qt.digia.com/4.6/qsignalspy.html#details
"Note: Non-standard data types need to be registered, using the qRegisterMetaType() function, before you can create a QSignalSpy."

http://doc.qt.digia.com/4.6/qmetatyp...gisterMetaType
"Any class or struct that has a public default constructor, a public copy constructor and a public destructor can be registered."

[prof.ebral]

It is based off QIODevice, correct? Don''t the readyRead and readChannelFinished signals work?

[wysota]

http://doc.qt.digia.com/4.6/qsignalspy.html#details
"Note: Non-standard data types need to be registered, using the qRegisterMetaType() function, before you can create a QSignalSpy."

I assure you "QObject*" is more than standard. Furthermore, what do you need a signal spy for? It's for testing only and there is a fine example in the docs showing you how to use it.

Seeing where it leads to, I'll ask the ultimate question -- why would you want to pass a QObject instance as an argument to a signal? Do you do that with e.g. QCheckBox?

[kuzulis]

@RolandHughes

About what kind of class are you talking? If this class of addon QtSerialPort, then:

...which will be included as part of Qt 5 according to the Web site.

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 addon.

At the moment, in fact, the development is supported and is active only one developer.

The examples are all kind of worthless.

Wow? O_o What makes you think that they are useless?

This Open Source project, no one is obliged to write to you. Write yourself a useful example in
your opinion, and then I will maybe I add your example to trunk.

The documentation says the SerialPort class is thread safe, yet, SerialPort.h deliberately disables a copy constructor which makes it very difficult to do signalling.

Where is it written that it is "thread safe"? It is not so.

I have found many cheating examples which call waitForReadyRead() instead of doing it right.

Where cheating? In BlockingMaster/BlockingSlave? O_o

Looking actual compiling example of SerialPort class using signals and slots within a thread which is NOT the GUI thread.

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

But they have not yet added to trunk.


Therefore, your conclusions are absolutely baseless and unconstructive.

[b-s-a]

RolandHughes, how to use SerialPort signals/slots from other thread:

//mythread.h
#include <QThread>
class MyThread : public QThread
{
   Q_OBJECT
protected:
   virtual void run();
};

//mythread.h
#include <QThread>
class MyThread : public QThread
{
   Q_OBJECT
protected:
   virtual void run();
};

To copy to clipboard, switch view to plain text mode 

//mythread.cpp
#include "mythread.h"
#include <QtAddOnSerialPort/serialport.h>
void MyThread::run()
{
   SerialPort port; //do not set parent or read manual for QObject::moveToThread()!
   //do some settings to port
   //do some signals/slots connections
   //do open the port
   exec(); //run event loop
}

//mythread.cpp
#include "mythread.h"
#include <QtAddOnSerialPort/serialport.h>
void MyThread::run()
{
   SerialPort port; //do not set parent or read manual for QObject::moveToThread()!
   //do some settings to port
   //do some signals/slots connections
   //do open the port
   exec(); //run event loop
}

To copy to clipboard, switch view to plain text mode 

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

[wysota]

Furthermore the question should be why to use a thread at all if one is going to use signals and slots instead of blocking waitFor* calls.

[b-s-a]

Furthermore the question should be why to use a thread at all if one is going to use signals and slots instead of blocking waitFor* calls.

Answer to this question should be very interesting.

[RolandHughes]

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.

[Lesiok]

RolandHughes, just use QExtSerialPort. It is working in threads.

[wysota]

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.

[RolandHughes]

RolandHughes, just use QExtSerialPort. It is working in threads.

That was my initial thought because I have used it before successfully, despite some quirks. That was before the requestor saw the wiki page which makes it sound like this new library is supposed to be part of Qt at some point. That, and there are persistent stories that QExtSerialPort isn't under development anymore. I may be forced to go back to that.

Thanks

---

Added after 21 minutes:

wysota,

Please stop replying to this thread. I do not know if it is a language barrier or what, but so far you haven't understood a single thing I've said. I thank you for your time.

You don't burn a thread when using signals and slots. Nobody says you should use waitFor*.

everyone who suggested the examples and unit tests were good "suggested" this since it is the only thing they used when not running in the GUI thread.

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.

No. Aparently you have never done data acquisition. Your assumption is completely invalid. We do have multiple cores, but you do not need one per thread, especially for serial. I've run a 16 serial ports flat out (115200 baud at each port) on a sub Ghz processor without ever losing anything.

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.

NOT EVEN CLOSE!

Tests left running over night or over the weekend generate millions of data points. Someone kicking off the GUI "report" to plot and graph outliers, or some other such "report" will bind that processor for minutes, if not hours. Don't compare this report to something you've done in school. Think SETI or some other serious research application where data points from a few minutes to a few days can completely fill a 1TB drive when stored in binary format. This is not two people chatting via some cheesey terminal.

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

Signals are dynamically mapped. Signals can easily get lost any time the entry in the signal map is missing or pointing to a null or pointing to an incorrect thread, hence why I was looking at the signal spy stuff as the next step.