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

**RolandHughes** · 12th December 2012, 13:59

I don't know who is "everyone" and what they "suggested", I'm not telling you to look at examples but to use QIODevice API like it is supposed to be used. You can search the Internet for similar discussions on doing networking with threads. "Everyone" "suggests" this is supposed to be done in threads because that's how they have been doing it using other technologies that didn't provide non-blocking API. It is not supposed to be done in threads.

Yes it is. Please do not try to view this application in terms of something running on a machine where the user can also surf the Web and check email.

Which is exactly my point. You don't need "non-blocking threads" (whatever you mean by that) to handle serial ports simply because the operating system will buffer data for you. If you are running 115200 baud transmission, it doesn't mean you need to read 115200 bits per second. It means you need to read 115200 per second on average. This is only 14kB per port, I'm sure single thread can handle reading 16 of these per second and still be able to do some fancy stuff in your UI.

That is very poor design and not allowed in a scientific environment were loss of a single data point scraps the entire test run.

Did it come to your mind to do this "minutes if not hours" lasting processing in a thread (or even in a separate process)? Are you really blocking your UI for "minutes if not hours" and still think that's ok? Are you sure it is me who never did any data aquisition and processing?

Oh jeez, and you want to process it in the GUI thread? That's so professional...

It is a design requirement. Do not confuse this with some application on a machine which has any other purpose or ability in life. The really large data sets can and do get off-loaded to serious computers for detailed analysis. The initial analysis to weed out non-interesting data sets occurs on the collection machine. What you consider a waste saves weeks and in some cases months of serious computing time.

You have to be kidding. If you are worried about it and are unable to check if that is really the case then do proper synchronization in your code.

Stop trolling and claiming to have all the answers and start reading on proper usage of components at hand. Your post on disabled copy constructor in a QObject subclass clearly shows how well you understand Qt code.

I'm not trolling or claiming to have all of the answers. I came in asking if there was unit test code proving this works. I got a bunch of responses which sounded like a Bing commercial.

My next debugging course was to use the signal tool, but any class which does not have a copy constructor cannot be used with it...a point you have repeatedly failed to recognize.

Please don't view this as a user application. This is a single purpose system running in an environment were no data point can be lost. Every device must be service by a non-blocking thread and those threads must be distributed across processors. It is not an end user application nor a hokey little smart phone app. It gathers all data points and the GUI only has two purposes. 1) Configure everything for a test run 2) run the reports/graphs used to identify interesting data sets. That's it.

Some of them might even not be emitted at all

Hence the wish to test with the signal tool.

Are you talking about your own projects or projects in general?

Projects which get released for use with Qt. I find they only provide unit test code/examples for GUI use, and nothing for use within non-GUI threads.

At any rate. This message thread can now end. I'm on my own fixing it or I have to switch to qextserial.

Added after 7 minutes:

As far as I understand data sent by signals is sent to the main thread. You are asking for this, "Looking actual compiling example of SerialPort class using signals and slots within a thread which is NOT the GUI thread."

http://doc.qt.digia.com/qt/threads-q...across-threads

Queued Connection The slot is invoked when control returns to the event loop of the receiver's thread. The slot is executed in the receiver's thread.