0

The Qt desktop GUI multithreaded application that I need to develop, is required to read from the serial port on one thread and display the read-data on another thread.

I am thinking of taking the following design approach.

Subclass a QObject to create a worker. Instantiate this worker object and a QThread. Move the worker to the new thread. Send data to the worker object over queued signal-slot connections.

Is this a good design approach? Or is there a better one?

Aham
  • 49
  • 1
  • 8
  • Welcome to Stack Overflow. Do you have some code you can include? Did you get an error when you tried this? Please give more information. – Travis Heeter Nov 23 '16 at 17:14
  • 1
    SO is a Q&A site. Welcoming "comments and suggestions" is not a question. Please edit the question to make it explicit what you ask. Otherwise the question is too broad. One could write a small book dissecting all things you should keep in mind in making design decisions such as yours. E.g. why is there a requirement for there to be multiple threads? Qt offers fully asynchronous serial port and networking interfaces, they can run on any thread with an event loop. Why do you think the main thread will be insufficient? Why doesn't the worker own the serial port? And so on. – Kuba hasn't forgotten Monica Nov 23 '16 at 17:35
  • @TravisHeeter, I do not have any code to show here. – Aham Nov 23 '16 at 17:55
  • @KubaOber, Thanks for the suggestion. I've edited the post. As you rightly said, this may not require 2 threads. But what I'm trying here is a sample application to demonstrate multithreading for serial port read and write operations and this application will be enhanced to include other functional features in future that would require more than one thread. – Aham Nov 23 '16 at 17:59
  • There's not enough detail: Does the worker own the serial port? What "data" is sent to the worker from another thread: high-level protocol data that gets encoded/decoded within the worker, or raw data? You also shouldn't need to worry about queued connections. Use the automatic connection type and [let Qt choose the appropriate connection type](http://stackoverflow.com/a/40728508/1329652). – Kuba hasn't forgotten Monica Nov 23 '16 at 18:11
  • Furthermore, having read the question (and answers) I'll [link to here again](http://stackoverflow.com/q/32486198/1329652), where it's demonstrated how to trivially decide whether the communications objects live on the main thread or not, do you still have any other questions left? – Kuba hasn't forgotten Monica Nov 23 '16 at 18:12
  • @KubaOber, it is going to be raw data for now. Since I am new to Qt, it would help if you can explain the thread-wise design approach. What I'm visualizing is the application reads from the serial port (on the main thread) which passes the raw data onto the worker thread that dumps it on a message box (on the worker thread). – Aham Nov 23 '16 at 18:23
  • @Sri Such a design is bad because: 1. You don't want the port to be running on a thread different than the worker - it will only make things slower. 2. The GUI elements must all reside in the main thread: it is invalid to access any `QWidget` methods from threads other than the main thread. – Kuba hasn't forgotten Monica Nov 23 '16 at 22:56
  • You always want the `QSerialPort` to be in the thread where you implement the communications protocol. But of course once the communications protocol has extracted the data, it can be processed in another thread if you wish so, although then you must parallelize the processing: the only reason why you may wish to move processing to another thread is that one thread (the communications one) was too slow. In that case, any **one** other thread will be too slow as well. In most cases, you want communications to be on a single object, that you optionally move to another thread. – Kuba hasn't forgotten Monica Nov 23 '16 at 22:59
  • @KubaOber, OK. So what I understand from you is this: (1) use the worker thread to open/read from/write to/close the serial port. (2) use the main thread to handle the widgets. I assume it is possible to pass the raw data from the worker thread onto the main thread. – Aham Nov 24 '16 at 12:34
  • That's correct. The passing of the data is done via the signal/slot mechanism and is transparent to you. – Kuba hasn't forgotten Monica Nov 25 '16 at 04:44

0 Answers0