Thread that read from QSerialPort

i'm developing an application that use QSerialPort.
I made two threads , one to read and one to write on the serial port.
I would like to know if i'm doing right..
this is the implementation of the Rx thread:

That is probably not the most efficient way of doing this. QSerialPort can be used either synchronously or asynchronously.

Synchronously: use waitForReadyRead or waitForBytesWritten, but this will block your thread until either data is received or written. This is bad if you use it in the GUI thread (i.e. the main Qt thread): your application will not respond to user input until the read or write is done.

Asynchronously: uses signal and slots. In this case you connect to the readyRead signal with your slot (ReadFromSerialPort), and each time data is available the signal will be emitted and your slot will be executed. Now you don't need to wait in a wasteful while loop for data reads or writes + no need for extra threads.
For more information how this is done internally check:https://qt-project.org/wiki/Threads_Events_QObjects#285a62c361be4793a6c10d04e3823a80

I highly recommend using the second approach, especially if you plan to use more Qt.

the problem is that i'm developing an application that communicate with an external interface with the serial port so it continuosly communicate with it while the GUI need to be responsive and accept user input/show values etc...

[quote author="t3685" date="1383215445"]No it is not correct. You don't need a wait loop like that.[/quote]rileo8 realized that after reading the documentation. That's why he asked if it's correct to replace the wait loop with exec().

the problem is...if i need that the worker thread receive signals from the GUI what i have to do? Connect with signal&slot the GUI withe theThread class and then connect always with signals/slot the thread calls with the worker class?

[quote author="t3685" date="1383215445"]No it is not correct. You don't need a wait loop like that.[/quote]rileo8 realized that after reading the documentation. That's why he asked if it's correct to replace the wait loop with exec().[/quote]

The QSerialPort class is asynchronous. You don't need threads to do this.

[quote author="t3685" date="1383225223"]The QSerialPort class is asynchronous. You don't need threads to do this.[/quote]Yes, if I/O is slow enough, then no threads are needed. That's why I asked about the read/write rate.

[quote author="JKSH" date="1383225543"][quote author="t3685" date="1383225223"]The QSerialPort class is asynchronous. You don't need threads to do this.[/quote]Yes, if I/O is slow enough, then no threads are needed. That's why I asked about the read/write rate.[/quote]

The write function returns immediately. The readyRead() signal is only emitted when data is available. I don't think it matters then what the Baud rate is.

[quote author="t3685" date="1383225815"]
The write function returns immediately. The readyRead() signal is only emitted when data is available. I don't think it matters then what the Baud rate is.[/quote]Sorry for being unclear; I meant the rate at which read() and write() need to be called (relative to other operations). An active thread will experience jitter, especially on a non-real-time OS. That raises the possibility of a buffer becoming empty. Depending on how the devices have been designed, an empty write buffer could kill the entire connection.

t3685 has a very valid point though. rileo8, try running your workers in the main thread first using the asynchronous API, and see how your program performs. You might not need 3 extra threads.