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

[wysota]

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.

And how is that related to anything we've been discussing about? I don't care where the application runs. I care that a single thread doesn't have any problems in reading data from multiple sockets/ports.

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

What is poor design and how does having another thread prevent loss of some data that would otherwise magically be lost? Data is not lost if you read it 10ms later or 20ms later or even 2 seconds later. It's still there. What matters is that you read data fast enough to prevent cluttering the input buffer. And even that is nothing wrong if you are using TCP as the protocol itself is designed to prevent any data loss. Your serial port doesn't have that safety mechanism and thus you need to pay attention to read the data fast enough to not overrun the input buffer for the port. But it totally doesn't matter which thread performs the read.

It is a design requirement. Do not confuse this with some application on a machine which has any other purpose or ability in life.

Strange. Somehow your flaws are "by design" (yeah yeah, it's a feature, not a bug) and something you consider a "flaw" in others' thinking is "unserious school project". Be serious. Any unresponsive system is badly designed. Period.

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.

Yes, you are trolling. Just read your posts.

a point you have repeatedly failed to recognize.

So... QPushButton is also badly designed because it also has a disabled copy constructor? What about QSignalSpy itself? It also has a disabled copy constructor. So does every QObject-derived class. And so does QtSerialPort which is a sign of good design on behalf of its author.

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.

I'm sorry but as a user of any user application I would not like to have any of my data lost too. And as a programmer of such applications I wouldn't want to have any data lost. Your system is by no means special.

Hence the wish to test with the signal tool.

If you test with the signal tool, the signal will be emitted because the connection from the tool will make its emitter emit it. I think you fail to understand what I meant. Read the docs for QObject::receivers() to see what I meant and how does QSignalSpy influence it.

Projects which get released for use with Qt.

No. My projects never loose any signals, they don't loose any "data points" nor anything like that. They often use multithreading and classes from them are often thread-safe. So please talk about your projects, not about others'.

This message thread can now end.

Thank you, your Grace, for giving us your permission

>____< I used the code you gave me. "I" did not do that. Anyway, thank you.

You subclassed QThread. I didn't.

[prof.ebral]

You subclassed QThread. I didn't.

I used the original code, then modified the code to show the thread Id. The original code did not work for me. I posted that. This conversation between you and me is of no value, and you seem to have a problem reading.

[wysota]

Look, the essential difference between code from posts #25 (mine) and #28 (yours) is that the code in post #28 subclasses QThread and connects to a slot from an instance of this class (lines 11-16 and 28). This is why you get the id of the main thread --- because QThread instance lives in the main thread. If you always do that in your code (meaning you connect a signal to a slot in the QThread subclass) then indeed all slots are executed in the context of the main thread, because that's where the QThread subclass instance lives. The modification you did in post #28 to my code from post #25 is what makes the difference between your output and mine.

[prof.ebral]

Wysota ... the Object doesn't even execute the reportThread method in your code, nor in mine. I'm trying to point that out to you. Like I said, you have a hard time reading.

Here ... I will quote my post:
"That doesn't work for me. I only receive the MainThread print statement in my terminal.

edit: wysota, here is some modified code and the output. Even after the Object class is moved to the Thread class I still get the main thread's ID ... but for me the signal is not being caught by the Object's reportThread method."

[wysota]

Wysota ... the Object doesn't even execute the reportThread method in your code, nor in mine. I'm trying to point that out to you. Like I said, you have a hard time reading.

I understand that it doesn't work for you, I don't know why. It works for me just fine and I'm sure it works for many other people because it is intended to work that way.

Even after the Object class is moved to the Thread class I still get the main thread's ID ... but for me the signal is not being caught by the Object's reportThread method."

You get the main thread ID's because you connect the timer's signal to the slot of an object that lives in main thread.

I just tried running the code you posted but it bails out with a syntax error (I'm using Python 3):

File "./code.py", line 11
    print self, (QtCore.QThread.currentThreadId())
             ^

File "./code.py", line 11
    print self, (QtCore.QThread.currentThreadId())
             ^

To copy to clipboard, switch view to plain text mode 

After fixing those syntax errors (by putting print arguments in parenthesis) and running the code, I get this:

<__main__.Object object at 0x7fa7c3b50b00> <__main__.Thread object at 0x7fa7c3b50a70> 140358524008192
MainThread 140358524008192
<__main__.Thread object at 0x7fa7c3b50a70> 140358524008192
<__main__.Object object at 0x7fa7c3b50b00> 140358466680576
<__main__.Thread object at 0x7fa7c3b50a70> 140358524008192
<__main__.Object object at 0x7fa7c3b50b00> 140358466680576

You can see two slots are called -- one in Object (with thread id 576) and the other one in Thread (with thread id 192). That's the correct behaviour as described in Qt docs (PyQt can't possibly work differently because it's just a wrapper over Qt C++ classes). I don't know why you're getting no output for Object, the most obvious reason is that the worker thread is not started (or its event loop is not running).

A side note: I checked with Python2.7 and it works the same way as with Python3:
(<__main__.Object object at 0x7fa08aaf7d40>, <__main__.Thread object at 0x7fa08aaf7cb0>, 140327479097088L)
MainThread 140327479097088
(<__main__.Thread object at 0x7fa08aaf7cb0>, 140327479097088L(<__main__.Object object at 0x7fa08aaf7d40>, 140327422002944L)
)
(<__main__.Thread object at 0x7fa08aaf7cb0>, 140327479097088L)
(<__main__.Object object at 0x7fa08aaf7d40>, 140327422002944L)
(<__main__.Thread object at 0x7fa08aaf7cb0>, 140327479097088L)
(<__main__.Object object at 0x7fa08aaf7d40>, 140327422002944L)

[prof.ebral]

You can see two slots are called -- one in Object (with thread id 576) and the other one in Thread (with thread id 192). That's the correct behaviour as described in Qt docs (PyQt can't possibly work differently because it's just a wrapper over Qt C++ classes). I don't know why you're getting no output for Object, the most obvious reason is that the worker thread is not started (or its event loop is not running).

That is why I subclassed it. The thread starts. You can modify the run or start methods and determine that if you want. I don't know why either.

[wysota]

The thread starts.

How do you know that? There is no code in your program that verifies if the thread is running.