Qt Labs Forum » Qt Concurrent

1. 
   smr99
   Member

   Hi,

   I have two questions:

   1. The docs state that you can cancel a mapped() operation, but not a run(). Why is that? The QFuture returned by run() still has a cancel() method. What happens when I call it?

   2. Suppose I use QFuture<Foo> f = run( makeFoo ); what is the suggested strategy in the case that makeFoo might throw an exception? As it stands, this crashes the application, since Qt just allows exceptions to propagate up. I could certainly put a try/catch inside makeFoo, but I'd like to get the exception passed back to the GUI thread, for use in error handling (e.g. it might have information that needs to be presented to the user). Any thoughts on how to design this? My first impulse is that QFutureWatcher needs another signal, alongside finished() and cancelled(), to signal an exception. But maybe this isn't appropriate for QtConcurrent and I should do it all myself?

   Posted: 1 year #

2. 
   Morten
   Member

   1: It depends. If the function is on the task queue waiting for a thread it will be canceled, but since there is no way to cancel a function call in C++ (other than terminating the thread, but that is evil), it's not possible to cancel it after the worker thread has called the function. You should be able to check isCanceled() to see if it actually was canceled.

   2: Exceptions across threads is a problem in c++. I think the ideal code would look somthing like this:

   
   QFuture<foo> f = run(makeFoo);
   
   // later
   try {
       useResult(f.result());
   } catch (...) {
   }

   The problem is that C++ does not allow catching an exception thrown in one thread, and then re-throwing it in another. Fixing this has been a topic for C++0X, see http://www.artima.com/cppsource/threads_meeting.html for example.

   As for solving this in Qt Conccurent it could be possible to add an exception() signal, but there would be no way of knowing what type of exception that had occured. I think the best way to solve this today is to embed the error messaging in the return value. It might even be possible to capture the exception data in the worker thread and then then throw a new exception when the result is used.

   Posted: 1 year #

RSS feed for this topic

Reply

You must log in to post.