Den tors 18 aug. 2022 16:44Sean Murphy via Interest <interest@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@qt-project.org > https://lists.qt-project.org/listinfo/interest >
_______________________________________________ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest