Den fre 31 jan. 2020 kl 17:25 skrev Sona Kurazyan <sona.kuraz...@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-boun...@qt-project.org> on behalf of Karsten > Heimrich <karsten.heimr...@qt.io> > Sent: Thursday, December 19, 2019 2:12 PM > To: development@qt-project.org <development@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@qt-project.org > https://lists.qt-project.org/listinfo/development _______________________________________________ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
