Important: Please read the Qt Code of Conduct - https://forum.qt.io/topic/113070/qt-code-of-conduct
How to cancel a long running API call running in a separate thread?
I'm looking for the best way to use QThreads to call a function that will take a long time in a separate thread whilst being able to stop the thread from the UI if the user wants to cancel the operation.
I've looked online and it seems the general idea is to add a boolean flag to the long running function and check every so often returning if needed but as the function is part of a library I cannot do this. I need the function to run in a different thread and to have the ability to cancel it allowing it to free its resources much like Ctrl-C would on the command line.
Is there any way to do this using Qt or perhaps something from std?
JonB last edited by JonB
allowing it to free its resources
You can terminate thread as @jsulm says. The problem is: how do you know what that thread/API has done so far, how do you know what non-thread resources it may have created and not cleaned-up/released?! Unless the API itself offers a "cancel" function, or you know just what it does, you take your life in your own hands! :)
A tricky problem it seems. I think the API call in this instance is self contained as in it will create resources of it's own but it won't modify anything outside of the thread I presumed these would all be taken care of when the thread is stopped but maybe this isn't the case...
So there is no 'good' way to do this? I am surprised as it seems like it would perhaps be quite a good thing to have but maybe it causes more issues than it solves/there are better ways of doing it!
Thanks for your responses.
JonB last edited by JonB
If the thread truly does only use its own, internal, "thread-local" resources, you may indeed be fine terminating it. But only you, or the API authors, know that!
Warning: This function is dangerous and its use is discouraged. The thread can be terminated at any point in its code path. Threads can be terminated while modifying data. There is no chance for the thread to clean up after itself, unlock any held mutexes, etc. In short, use this function only if absolutely necessary.
If it only modifies its own data, and doesn't interact with the OS, you should be OK. But don't blame us if it turns out to be halfway through writing to a file! :)
Note: one difference from your Ctrl+C example is that a program can trap that signal and clean up nicely. Terminating a thread does not allow that. Think of it more like using Task Manager End Task or
kill -9on a process.
I presumed these would all be taken care of when the thread is stopped
How? If you terminate the thread then it is terminated, only you know what you do in the thread and it is your job to clean up, there is no magic.
"So there is no 'good' way to do this?" - the good way would be to have an API which allows to interrupt long lasting operations in a clean way...
I think the API call in this instance is self contained as in it will create resources of it's own but it won't modify anything outside of the thread I presumed these would all be taken care of when the thread is stopped but maybe this isn't the case...
A well-designed API should not block for an extended period of time. Instead, it should provide a proper way for you to "abort"/"cancel" the current operation and clean up its resources.
If the API is not well-designed, then you're stuck. You can either wait until it finishes, or you can terminate it and pray that the termination doesn't break anything.
A well-designed API should not block for an extended period of time.
Or at least should provide a way to set timeout for a blocking operation, which many APIs unfortunately don't; so what @JKSH wrote.