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.
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@qt-project.org
https://lists.qt-project.org/listinfo/interest
