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

[Elvis Stansvik]

Den tors 18 aug. 2022 16:44Sean Murphy via Interest <interest at qt-project.org>
skrev:

> > > 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).
>
> Yeah, and that seems to be the rub with the QtConcurrent functions, I don't
> get any sort of handle to the threads it is spawning off, unless maybe I
> can get
> at them via the global thread pool?


Yes, it uses the global threadpool by default I think.

I guess the problem with eg an API to get the list of threads used by a
::map call is that it would be inherently racy - by the time you kill a
thread it could have been put back into and out of the pool already and be
running something you don't want to kill?

So maybe better with a custom pool.

Elvis

I'm just starting to look at that. Other than
> trying to call cancel() on the associated QFutureWatcher, which does work
> eventually as long as your function called by map() actually returns,
> there doesn't
> seem to be a way to stop those concurrent threads.
>
> With the way my code exists at the moment, I've got the main application
> running
> in the UI thread. I intentionally spawn off Thread A and move my
> processingManager
> object over to that thread, and when that object gets a processing
> request, it  calls
> QtConcurrent::map() which spawns off Threads B, C, D, etc... and I don't
> seem to have
> any control over those threads. I know when I had the infinite loop bug in
> my
> processChunk() call, killing off Thread A (the processingManager's thread)
> and deleting
> the processingManager itself didn't seem to forcefully terminate Threads B
> through
> whatever - they just kept on running forever. I'm going to try writing up
> a small test app to
> double check this. I was doing all this in the main application, which has
> a whole lot of
> other stuff going on, so maybe my issue was somewhere else...
>
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/interest/attachments/20220818/2cc439b5/attachment.htm>