[Interest] [External] Re: How to properly terminate QtConcurrent run

[Elvis Stansvik]

Den ons 17 aug. 2022 kl 17:12 skrev Sean Murphy via Interest
<interest at qt-project.org>:
>
> Thanks for the response!
>
> > You should signal processChunk to stop processing early. You can for
> > example do this through an atomic variable which is periodically checked, e.g.
> > as part of the stop condition in that loop you mentioned.
>
> I'll look into this idea, but some of what my processChunk() does are calls into an
> external library that I can't control so my options are limited there. As far as I can
> tell, this is an issue for any code that just takes a long time.

Yes, if this it's a call into an external API that provides no
mechanism to cancel the call prematurely, you have no option for
graceful shutdown and have to kill the threads forcefully.

I guess in the code handling your application exit, you can wait a
little bit for all threads in the pool, and after an "unreasonable"
amount of time has passed (half a second?), kill them all forcefully.
Bit of a big hammer, but I don't know of any way to query for the
threads currently used by a specific ::map call (maybe someone else
does though).

Elvis

>
> Take this hypothetical scenario for example:
>  - we have some processing task that would take hours to run if run in a single thread,
>     but it can be broken down into chunks
>  - once broken into chunks, each chunk takes maybe a minute to run, but most of
>     that minute is consumed in an external library that I can't do anything about
>  - user starts one of these tasks, but before it finishes they decide they don't care
>     about the results and want to completely quit the application
>  - I warn the user there's a job in progress, are they sure they want to quit? They say Yes
>
> So at this point, the user really wants to quit the application. From what I've gleaned so
> far, and I could be wrong so feel free to correct me, I can tell the QFutureWatcher to
> cancel the job. But this only prevents any chunks that hadn't been started from getting
> started, it doesn't immediately terminate the chunks that are currently in progress,
> those continue until they all finish, at which point the QFutureWatcher signals both
> canceled() and finished(), and now I can safely quit the application. But if it were me as
> the user, I'd be annoyed that I have to wait up to a minute for the application to quit
> after I asked it to quit.
>
> > I may be wrong, but I think terminating a thread forcefully is considered a
> > poor design.
>
> In general I agree, but I'm not sure I do in the special case of the user quitting the application
> under the conditions I've described above. At that point to me (this is me wearing my user hat
> now, not my developer hat), I would want the application to quit immediately and I don't really
> care what happens under the hood - as long as it doesn't crash.
>
> (Developer hat back on) I don't see a way to easily accomplish this under the QtConcurrent
> API. Most of the examples I can find online show how to do the set up part, but they rarely
> give any time to showing how to cleanly abort a run in progress. The only actual solution I
> see that can do this cleanly is to ditch QtConcurrent, and write my own chunkProcessor
> objects that spawn and manage their own worker threads, which when signaled, can forcefully
> terminate regardless of what is being done at the time.
>
> I'm open to suggestions/corrections/etc. Also, if anyone has any references they like that talk
> more about quitting/cleaning up threads under all sorts of different scenarios, I'd love to read
> more about it - I seem to be struggling to find those.
>
> Sean
> This e-mail, including any attached files, may contain confidential information, privileged information and/or trade secrets for the sole use of the intended recipient. Any review, use, distribution, or disclosure by others is strictly prohibited. If you are not the intended recipient (or authorized to receive information for the intended recipient), please contact the sender by reply e-mail and delete all copies of this message.
> _______________________________________________
> Interest mailing list
> Interest at qt-project.org
> https://lists.qt-project.org/listinfo/interest