Why cross-thread invoke will report “QObject: Cannot create children for a parent that is in a different thread.”？
-
@J.Hilk But If I just call a funcation like
QSerialPort::write(), there is no qobject created in the whole process.That's your a assumption, and sometimes it's not tenable.@Crawl-W
of course, that's my assumption, you haven't shown any code. What else can I do but assume ?
Be aware of the Qt Code of Conduct, when posting : https://forum.qt.io/topic/113070/qt-code-of-conduct
Q: What's that?
A: It's blue light.
Q: What does it do?
A: It turns blue. -
@Crawl-W
of course, that's my assumption, you haven't shown any code. What else can I do but assume ? -
@J.Hilk About
QSerialPort::write()orQSerialPort::open()? I had tried to seach the source, but no object created seemingly.@Crawl.W What else do you do in that other thread?
-
@Crawl.W said in Why cross-thread invoke will report “QObject: Cannot create children for a parent that is in a different thread.”？:
noting.
You are doing something or you would not have this error message.
If you don't want to show your code, then you will have to find yourself where you create a QObject instance with a parent in a different thread.It is an old maxim of mine that when you have excluded the impossible, whatever remains, however improbable, must be the truth. (Sherlock Holmes)
-
@Crawl.W said in Why cross-thread invoke will report “QObject: Cannot create children for a parent that is in a different thread.”？:
noting.
You are doing something or you would not have this error message.
If you don't want to show your code, then you will have to find yourself where you create a QObject instance with a parent in a different thread. -
now it's obvious.
Your singleton is created in the main thread. you write to it inside the worker thread. during write process, a QTimer is created and set, to monitor timeouts. That is created from the wrong thread of course. -> Therefore the error
Be aware of the Qt Code of Conduct, when posting : https://forum.qt.io/topic/113070/qt-code-of-conduct
Q: What's that?
A: It's blue light.
Q: What does it do?
A: It turns blue. -
now it's obvious.
Your singleton is created in the main thread. you write to it inside the worker thread. during write process, a QTimer is created and set, to monitor timeouts. That is created from the wrong thread of course. -> Therefore the error
-
@J.Hilk So it is,You rocks!But I did not find where
QTimercreated, can you post those source? -
now it's obvious.
Your singleton is created in the main thread. you write to it inside the worker thread. during write process, a QTimer is created and set, to monitor timeouts. That is created from the wrong thread of course. -> Therefore the error
-
@J.Hilk As show in source,the
QTimeris very strange, which is single shot and no interval set.Why?Why do not call his timeout's slot function directly?@Crawl.W said in Why cross-thread invoke will report “QObject: Cannot create children for a parent that is in a different thread.”？:
Why do not call his timeout's slot function directly?
Because then it would be a synchronous call - write() would block until it's finished. But since it is an asynchronous API it should not block the caller.
-
@J.Hilk As show in source,the
QTimeris very strange, which is single shot and no interval set.Why?Why do not call his timeout's slot function directly?@Crawl.W said in Why cross-thread invoke will report “QObject: Cannot create children for a parent that is in a different thread.”？:
Why do not call his timeout's slot function directly?
This is done to call the timeout function after all events in thread queue have been processed.
Here the extract for QTimer::interval:The default value for this property is 0. A QTimer with a timeout interval of 0 will time out as soon as all the events in the window system's event queue have been processed
-
@Crawl.W said in Why cross-thread invoke will report “QObject: Cannot create children for a parent that is in a different thread.”？:
Why do not call his timeout's slot function directly?
Because then it would be a synchronous call - write() would block until it's finished. But since it is an asynchronous API it should not block the caller.
