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

[wysota]

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.

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.

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.

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.

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.

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?

Don't compare this report to something you've done in school

We never did that in school because by the time I was finishing school we were running a single 56k modem shared by around 20 machines.

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.

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

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.

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.

---

Added after 6 minutes:

Please learn just a tiny bit about a library before inserting your foot so far into your mouth.

I think Kuzulis knows best of us how the QtSerialPort library works.

Signals are lost in most Qt applications and this is be design. When you use an object which emits signals do you assign a slot to catch each and every signal? No. You assign a slot to catch only the signal you are interested in. ALL THE OTHER SIGNALS EMITTED BY THE OBJECT ARE LOST.

So that's what you mean by a "lost" signal... I would rather call that "ignored".

They have no entry in the dynamically created table matching signals to slots within and across threads. They are emitted and lost.

Some of them might even not be emitted at all

When new "projects" get added, sometimes they don't do things correctly when creating entries for non-GUI threads. When this happens, the signals emitted which do not have routing entries in the table are LOST.

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