[SOLVED] Split Terminal example into Two threads

Sen Li

@Leonardo
Actually one of the reasons I want it to be multi-threads is, the working speed to retrieve data would not reduce by half.
The priority is to let them work as fast as possible.

Sen Li

@stereomatchingkiss
The priority is to let multi-sensors work simultaneously on the fastest speed to get data back; that is why I want it to be multi-threads.

I read a lot documents of Qt threading, and am working on "splitting" the "MainWindow" apart from QMainWindow (QWidget), and try to put it in QObject so that it could be in a new thread.

However, as a newbie of Qt, that is not easy; or I do not even know is that possible or not.

Leonardo

You're underestimating your application. I think your code is able to process the received data faster than the serial port can transmit new data.

If you're still interested in threads, you don't need to split the mainwindow. Keep the main gui where it is and move the serial port handling logic to a separate thread. Then you should emit signals that the main window will catch whenever a gui update is required.

Sen Li

@Leonardo
Yes, you are right.
The bottleneck could be serial port transmit, that is why I want the serial port communication to be in a new thread, how many sensors means how many COMs.

The serial port handling logic was written in "MainWindow", and my aim is to split that part to put it in a new thread.

We got the same idea.

Leonardo

If you agree that the serial port is the bottleneck, then you don't need threads. It seems like you think that QSerialPort would not handle both ports properly, but that's not the case. As I said before, QSerialPort is non-blocking by design. It implies that somehow threads are already used in its internals. Your application will not block while reading data, only when processing it in the readReady() signal, which should be very fast.

Sen Li

@Leonardo
Seems great!
I will try it and talk about it with you later.

Thank you!

Sen Li

@Leonardo
Hi,

It comes out that, the slot in SerialPort related Object never works;

myDefaulSerialObject = new SenSerialControlAlgorithmObject();
mySerialThread = new QThread();
myDefaulSerialObject->moveToThread(mySerialThread); // It works well if I Comment Select this line and without Qt::QueuedConnection

even if without moving the Object into a new thread, just added Qt::QueuedConnection after SIGNAl/SLOT, the slot doesn't work, either.

connect(this, SIGNAL(emitOpenSerialOrder(SenSettingsDialog::Settings)), myDefaulSerialObject, SLOT(openSerialPort(SenSettingsDialog::Settings)), Qt::QueuedConnection);

Is that only because of its non-blocking attribute, so that I cannot even use Qt::QueuedConnection in main thread?

Thank you!

Leonardo

Hi. I thought you were going to use the QSerialPort class. I don't know this class you're using.

Jeroen3

When using QSerialPort the bottleneck often exists in the plotting or showing of the data.
The ui widgets are to slow to keep up with a 100% loaded 9600 8n1 bus. This also applies to VC++ and C#.

To get asynchronous and more flexible you could move your serialport to a different thread/process and then converting it to a TCP socket. Localhost sockets are fast, and buffered.

Bonus:

you are able to read sensors over the network.
if the port crashes, the gui (with the data) doesn't.
your gui is truly platform independent.
I did something similar. But instead of using two ports, I merged data over 1 port, called MultiTerminal.

Sen Li

@Jeroen3
Thank you for your sharing!