It seems like everyone agrees that we need to keep and improve the asynchronous APIs in Qt 6. Since there are already tasks for each of proposed changes, let’s move more detailed discussions about each item to the relevant task. They are all linked to https://bugreports.qt.io/browse/QTBUG-80908. Feel free to make comments if you are interested.
Best regards, Sona From: Development <[email protected]> On Behalf Of Sona Kurazyan Sent: Friday, 31 January 2020 17:24 To: [email protected] Subject: Re: [Development] Make a decision for asynchronous APIs 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) 1. Officially document QFutureInterface and rename it to QPromise (https://bugreports.qt.io/browse/QTBUG-81586) 2. Add support for continuations to QFuture (https://bugreports.qt.io/browse/QTBUG-81587) 3. Provide a way of integrating QFuture with signals (https://bugreports.qt.io/browse/QTBUG-81589) 4. Improve the error reporting of QFuture (https://bugreports.qt.io/browse/QTBUG-81588) QtConcurrent 1. Rename QtConcurrent::run to qAsync() and modernize it (https://bugreports.qt.io/browse/QTBUG-81590) 2. Allow passing a QThreadPool* as a parameter to QtConcurrent algorithms to avoid exhausting all system threads. 3. Fix the algorithms which do not work with lambdas (https://bugreports.qt.io/browse/QTBUG-33735) 4. Add initial values to map/filter reduce (https://bugreports.qt.io/browse/QTBUG-73240) 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? Please share your thoughts! Thanks, Sona ________________________________ From: Development <[email protected]<mailto:[email protected]>> on behalf of Karsten Heimrich <[email protected]<mailto:[email protected]>> Sent: Thursday, December 19, 2019 2:12 PM To: [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>> 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 [email protected] https://lists.qt-project.org/listinfo/development
