On 11/05/2011 03:12 AM, Vincent van Ravesteijn wrote: > Op 4-11-2011 22:44, Richard Heck schreef: >> Hey, all, >> >> I've been working on making it possible to cancel an export in the >> background. I have it working at least part of the way. The problem is >> most obvious with XHTML export of the math manual. When we are doing >> that, we will have to generate images for some of the math. This >> involves starting an external program and waiting for the result. But >> when I call cancel() on the QFutureWatcher we have from QtConcurrent, >> this seems to kill the external program, and then the background thread >> just sits there and waits for it never to finish. >> >> Somehow, then, I need to interrupt this process. I tried deleting the >> PreviewLoader before calling cancel(), but this crashes because the >> background processing is still happening, and we think we still need a >> loader. Anyone have any ideas? >> >> I'm attaching the work done so far if anyone wants to play with it. The >> first two patches change from using QtConcurrent::run to >> QtConcurrent::mapped, because run() does not allow cancelling for some >> reason. The real action is in the third patch, and then the fourth one >> is my failed attempt to work around the problem just described. >> >> Richard >> > > It's not really clear to me what Qt means by cancelling a thread. > Without any knowledge of the code being executed in the thread, I > don't know how Qt can make the thread stop nicely. > What I had in mind way something like throwing an exception in that thread that would cause the executing function (doExport, usually) to return early. There are issues there, too, though, e.g. that the background image creation is also still going on, though maybe there's a way to cancel those processes, too.
> My feeling says we should acquire all information about which files we > need to convert. Then we convert them one by one (or make it parallel) > and then after each processed file, we should check whether the thread > has been cancelled by the UI or not. If not, we continue. This would > also allow us to return progress information to the UI. > Yes, well, I agree there might be a better way to do this overall, but reworking the export machinery isn't something I have time to do right now. Unfortunately, I'm starting to think QtConcurrent doesn't expose enough for this to be possible. Richard
