The module description can be found here QtConcurrent
The general question being asked is if we want to keep/deprecate the current implementation of
and the implementation of
Some discussion on the mailing list can be found here and in the related task (
There are a also a code and run generator using these APIs that can be found here qtconcurrent and a related discussion happened here
Also there needs to be mentioned that Qt Creator and the Qt Installer framework
use a extended/modified version of the above mentioned APIs in there own have extensions Link implemented to better use the above APIs source code.
Some further links around QFuture, QtConcurrent:
- KDE: asyncqt
- Ben Lau: AsyncFuture
- Chaining QFutures: QFutureBuilder
- Tasks that should be reevaluated: Jira
- Blog post: Multithreaded Programming with Future & Promise
Some research has already been done and what we gathered so far:
- QFutureInterface should become a QPromise and should be properly documented.
- QFuture should support continuations. Add QFuture::then, to make it similar to the upcoming C++20 std::future.
- Deprecate the job-like API of QFuture (progress, pause, cancel, etc.) and support of multiple results.
These are specific to QtConcurrent, and don't make much sense for a QFuture for general use.
- If we keep QtConcurrent (seems like we have to, because the parallel algorithms in C++17 do not support executors), we still need to have a future with the old functionality
(progress, pause, cancel, etc.), so we can make QtConcurrent::future out of the current QFuture and implement it based on the new QFuture.
- Add the following possibilities for creating a QFuture:
- add something like qAsync (similar to std::async) in QtCore, which basically does the same as QtConcurrent::run
- add something like make_ready_future and make_exceptional_future
- Support future composition similar to when_all and when_any
- Add unwrapping constructor that unwraps the outer future of a wrapped future (QFuture<QFuture<T>> -> QFuture<T>)
- Maybe also add QPackagedTask to keep compatibility with STL.
Since both the implementation in Qt Creator and IFW use QFuture|QtConcurrent in a slightly different manner, it might also make sense to evaluate and implement a more Task/Job like oriented abstraction, for example found in C#:
or ThreadWeaver, KJobs
So probably the first question that needs to be answered is if we want to go/keep the Future-Task kinda mixed design or if we want to strip the implementation down and add/improve on missing features and stuff std::future will bring first with C++20?