Uploaded image for project: 'Qt'
  1. Qt
  2. QTBUG-80908

Asynchronous APIs in Qt



    • Type: Epic
    • Status: Closed
    • Priority: P2: Important
    • Resolution: Done
    • Affects Version/s: None
    • Fix Version/s: 6.0.0, 6.0
    • Component/s: Core: QtConcurrent
    • Labels:
    • Epic Name:


      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 (QTBUG-61928).
      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:

      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?


          Issue Links

          No reviews matched the request. Check your Options in the drop-down menu of this sections header.



              sonakur Sona Kurazyan
              heimrich Karsten Heimrich
              PM Owner:
              Maurice Kalinowski Maurice Kalinowski
              RnD Owner:
              Alex Blasche Alex Blasche
              6 Vote for this issue
              34 Start watching this issue



                  Gerrit Reviews

                  There are no open Gerrit changes