[Development] Make a decision for asynchronous APIs

[Elvis Stansvik]

Den fre 31 jan. 2020 kl 17:25 skrev Sona Kurazyan <sona.kurazyan at qt.io>:
>
> Hi everyone,
>
>
>
> It's been a while since we've started discussions on this topic. I would like to summarize the outcome of these discussions and propose improvements to our asynchronous APIs based on the feedback we've received so far.
>
>
>
> First of all, there was a question weather we should keep QtConcurrent and QFuture (and related classes) at all, and the answer seems to be "yes", because the corresponding STL alternatives are still lacking a lot of features: std::future still doesn't support continuations, its API is not finalized yet, no executors are supported for parallel algorithms in C++17, etc. Additionally, Qt's asynchronous APIs have extensions like cancelling, pausing, resuming and progress reporting (although not everyone agrees that these extensions fit with a typical future, but they can be useful in Qt-specific use-cases, for example GUI applications).
>
>
>
> On the other hand, there are couple of improvements to be applied to QtConcurrent and QFuture* , to make them more useful and keep them in Qt 6. Here's the list of suggestions I've collected:
>
>
>
> QFuture (and related classes)
>
> Officially document QFutureInterface and rename it to QPromise (https://bugreports.qt.io/browse/QTBUG-81586)
> Add support for continuations to QFuture (https://bugreports.qt.io/browse/QTBUG-81587)
> Provide a way of integrating QFuture with signals (https://bugreports.qt.io/browse/QTBUG-81589)
> Improve the error reporting of QFuture (https://bugreports.qt.io/browse/QTBUG-81588)
>
>
>
> QtConcurrent
>
> Rename QtConcurrent::run to qAsync() and modernize it (https://bugreports.qt.io/browse/QTBUG-81590)
> Allow passing a QThreadPool* as a parameter to QtConcurrent algorithms to avoid exhausting all system threads.
> Fix the algorithms which do not work with lambdas (https://bugreports.qt.io/browse/QTBUG-33735)
> Add initial values to map/filter reduce (https://bugreports.qt.io/browse/QTBUG-73240)

Even if I've not read all the links, to me as a user of QtConcurrent
these all sounds like great improvements, bringing significant value.

>
>
>
> It would be nice to hear some opinions, to see whether this is a right direction to go, and if it makes sense to put our effort on these improvements. Is there anything important I’m missing in the list? Or maybe some of these items do not add much value?
>
>
>
> Additionally, there are some discussions about QFuture being a mix between a “Task” and a “Future”. One of the options of improving this situation is to make a QTask (or QJob) out of the current QFuture. But then the question is: should we also support a “classic” QFuture? Is there a value in having it, when there are already some very advanced implementations of a future?

I don't have too much to comment on this. Would the alternative to
QFuture in this scenario be a future class from somewhere else
(std::future, ...)? And the Qt goodies like
cancel/pause/resume/progress API would be on QTask?

Elvis

>
>
>
> Please share your thoughts!
>
>
>
> Thanks,
>
> Sona
>
>
>
> ________________________________
>
> From: Development <development-bounces at qt-project.org> on behalf of Karsten Heimrich <Karsten.Heimrich at qt.io>
> Sent: Thursday, December 19, 2019 2:12 PM
> To: development at qt-project.org <development at qt-project.org>
> Subject: [Development] Make a decision for asynchronous APIs
>
>
>
> Hi,
>
> we are planning to continue some work on the QFuture, QtConcurrent APIs, either improve up on the existing implementation or deprecate and remove them completely for Qt6. We’ve created a user story in Jira and  like to gather some feedback here. So if this topic is of interest for you, I would like to point you to https://bugreports.qt.io/browse/QTBUG-80908 to place some comments there.
>
>
>
> BR, Karsten
>
>
>
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> https://lists.qt-project.org/listinfo/development