I am working on a project that involves asynchronous generation of content in a worker thread. At first, I was using QtConcurrent::run and QFutureWatcher to manage fetching of job results. Multithreading my application tool ~5 lines of code and life was good.

However, we needed some functionality that QtConcurrent::run could not provide---particularly the ability to prioritize and cancel jobs. So, we switched from QtConcurrent to a more traditional hand-implemented worker thread. This is all working fine, but I've been doing a lot of work to implement an object that the calling thread can use to recieve results from the worker thread. Today I realized that I have put in a lot of effort to implement what is basically a poor man's version of QFuture.

It would be very, very, very nice if I could construct a QFuture<ResultType> to hand back to the calling thread and later call setResults on the future inside the worker thread followed by a function call that causes the QFuture to enter a "finished" state. Then I could remove hundreds of lines of custom code, use QFutureWatcher to wait for results in my calling thread, and life would be awesome again.