Cannot create children for a parent that is in a different thread.

BlueManCZ

I have an object instance of the class (let's say controller) with QNetworkManager instance in one of its fields. The instance of this controller is created in one thread. Now, I access and use this controller from other program threads and everything works fine. But when the controller sends an HTTP request, I get this warning:

[warn:default] QObject: Cannot create children for a parent that is in a different thread.
(Parent is QNetworkAccessManager(0x55969f574bc0), parent's thread is QThread(0x55969f22aee0), current thread is QThreadPoolThread(0x7f155005cb70)

I understand this warning, it's well explained in multiple posts on this forum.

But my code works without any problems and I don't feel the pressure to change anything. Is there any way to get rid of these warnings?

I would provide the code, but it's extensive, so I link it up against my GitHub repository:

SGaist

Hi,

There's your issue. I am guessing your are moving an instance of SpotifyWebAPI to a different thread. However, your QNAM instance is not moved as it's not parented to its containing class. Therefore it still lives in the thread that created the SpotifyWebAPI instance. Give it a parent.

It will have the added benefit of also removing the leak you have here since you do not destroy the QNAM object in your destructor.

BlueManCZ

Hello @SGaist,

thank you for your reply. I guess you could be right, it makes sense. I made those changes but warnings are still there.

Am I missing something else?

SpotifyWebAPI instance is created in: Constructor thread QThread(0x55969f574bc0).
After that, methods of this instance are called from pooled threads: QThreadPoolThread(0x7f155005cb70, name = "Thread (pooled)").

When I create a new instance of SpotifyWebAPI in each pooled thread, it solves the warning, but I need one persistent instance of SpotifyWebAPI for all pooled threads.

BlueManCZ

I managed to reduce the frequency of warnings by creating a new instance of QNAM in each thread, but it is still not optimal, because those threads run parallel and sometimes happens that one thread accesses QNAM instance created by another thread.

Christian Ehrlicher

@BlueManCZ said in Cannot create children for a parent that is in a different thread.:

sometimes happens that one thread accesses QNAM instance created by another thread.

So fix it - this must not happen to make it work correctly.

BlueManCZ

if (manager->thread() != QThread::currentThread()) {
    return false;
}

QNetworkReply *reply = manager->get(request);

I added this condition to avoid thread to use QNAM instance created by another thread, and it seems to work fine. The only thing that worries me now is how QNAM instance is created very often and sometimes (in case of this condition) quite unnecessarily.

Maybe it is not a big deal? Is QNAM object so lightweight that I can afford to create it quite often?

Christian Ehrlicher

I don't see a need for user threads for network operations at all...

BlueManCZ

@Christian-Ehrlicher said in Cannot create children for a parent that is in a different thread.:

I don't see a need for user threads for network operations at all...

Well, my code is an extension for the bigger project. Query handlers of all extensions in this project are called in parallel threads and I can't do anything with it.