QThread creation in separate thread

Nubcake

I am creating an application that involves connecting to a server but I as a QT novice, I would like to hear some expert QT advice.
My application is built upon an existing code base where the previous user who wrote it has created an object for connecting to the server and having it run in a QThread object through moveToThread.

Currently, the function for connecting to the server comes from an API, and the it blocks the thread until it completes. My problem is that I need to be able to cancel this request at anytime and the only way I can do it is by calling terminate() on the thread (I know terminate() is bad but this is the only way it seems). This seems to work. but every time I create the QThread, I get the warning

"QObject: Cannot create children for a parent that is in a different thread"

Nevertheless, my code seems to run fine despite this warning (or is it an error?). But my question is, is it safe to ignore this warning? What are the consequences/risks of ignoring this warning?
Why can't we create new threads that run in different threads to the place where they were created?

My other question is, is it safe to call start() on a QThread that finished through quit() or terminate()?

Thanks

SGaist

Hi,

Calling terminate should only be done as last resort as explained in the documentation.

Doesn't the API you are using provide a way to cancel the request ?

Nubcake

@SGaist I know that terminate() should be used as a last resort but if I don't terminate the thread, the request goes to the server which I don't want. The API doesn't provide any method to cancel a request which is forcing me to do this bad thread model.

SGaist

What is the case when you want to do such a cancellation ?

Nubcake

@SGaist When the network connection drops in my application, the user needs to be disconnected.
Back to question about the QThread warning, is it safe to ignore it?

SGaist

If the connection drops... How is that remote API supposed to be invoked ?

By the way, is that API publicly accessible ?

Nubcake

@SGaist What do you mean?
Unfortunately no, it's not a public API

SGaist

I mean that if your network connections drop, how is that API supposed to get your user disconnected since it won't be able to reach the server anyway ?

aha_1980

@Nubcake

Of course it is not good to ignore warnings. they tell you that something works differently than designed/expected and may lead to problems anytime.

regarding the API: if you terminate the thread, the API is unable to do needed cleanups, so memory or resource leaks may appear.

best would be imho, to improve the API so you dont need to terminate it.

Regards