[Solved] QtSerialPort and threading

[egonuel]

Hi all,

I'm working on a windows app, that should read data from different sensors mainly from the serialport. To add those I'm using the QtSerialport module and it works fine so far. Some of the sensors are delivering data with a frequency up to 512 Hz and hence are producing some activity. Which was until now not a problem as the development machine is a quite potent one. Yesterday I had to test the app on a lower powered laptop and unfortunately it was not able to fullfill its task: the data came in so frequently, that the event queue was filled up and the UI got unresponsible. My usual response to that is to create a second thread, move the hard working object to this thread and let the UI run smoothly again, not being influenced by the other object. But doing so with the QtSerialport seems to be not supported as the port presents me with an output like this once the port is being opened:
@QObject: Cannot create children for a parent that is in a different thread.
(Parent is SerialPort(0x24a1738), parent's thread is QThread(0x24a1770), current thread is QThread(0x18a8b0)
QObject: Cannot create children for a parent that is in a different thread.
(Parent is SerialPort(0x24a1738), parent's thread is QThread(0x24a1770), current thread is QThread(0x18a8b0)@
My app then produces some crashes and so I built a smaller testapp just reading one serialport.
Same output as above, but at least no crashes and the data is being read.
But I believe that those warnings may have a reason and some objects not being created is not something good to happen (or not to happen in this case;-)).
Apparently some object deep inside the SerialPort is not moved to the new thread and hence is producing that warning.
Why does this happen and is there a technical reason to behave like this, and if that's the case, what is the recommended way to handle situations like the one described above? Or can this be considered as a bug, which should be reported?

Greetings
Immanuel

[JKSH]

Did you try to open the SerialPort from your main thread? I'm guessing the open() function causes child objects to be created. Try open()-ing the port from the other thread instead.

[kuzulis]

2 egonuel

And how do you create an object of class of serial port?

@port = new SerialPort(this);@

or

@port = new SerialPort();@

[egonuel]

Thank you both for your answers.
open()-ing from the other thread seems to do the trick here. (I used new SerialPort(), as one can't move objects with parents.)
To achieve this I wrote a small wrapper class, which contains the serialport and provides slots for open and close, as the SerialPort functions are not declared as such.
Is there a way to avoid writting a wrapper class here? (No one comes to my mind right now.) The open() and close() functions are normal members as the SerialPort inherites from the QIODevice, right?
Nevertheless: I'm glad it works now, thanks! :)

[JKSH]

If you only open it once in your entire program, you might be able to open it first, and THEN move it to the other thread -- I believe its children will be moved too.

How are you reading data from the port, though? AFAIK, you can only grab data from a QIODevice via direct function calls. If you're doing that across threads, you might run into strange and subtle errors in the future

[egonuel]

Yeah you are right, I did not thought about that, while writing my last post. In my app the port was allready wrapped before and the reading is done by direct function calls from the same thread the port belongs to. I did wrap the open() and close(), but called those wrapped functions directly from the UI thread, hence the warnings, I originally asked about, after I moved the wrapper object to the new thread. Now I'm connecting to these functions and everything works fine.

[JKSH]

Good to hear :)

Please edit your original post and add "[Solved]" to the title