Re: [Development] Make a decision for asynchronous APIs
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 On Behalf Of Sona Kurazyan Sent: Friday, 31 January 2020 17:24 To: development@qt-project.org 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 mailto:development-boun...@qt-project.org>> on behalf of Karsten Heimrich mailto:karsten.heimr...@qt.io>> Sent: Thursday, December 19, 2019 2:12 PM To: development@qt-project.org<mailto:development@qt-project.org> mailto: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
Re: [Development] Make a decision for asynchronous APIs
Sorry, that was a typo, I should have written “resumability” , i.e. pause/resume. Can you also elaborate what do you mean by «reusability»? Ability to do something like future.restart(); ? 1 февр. 2020 г., в 14:44, Sona Kurazyan mailto:sona.kuraz...@qt.io>> написал(а): In my understanding a future represents a single result of a computation which will be available sometime in future, it doesn’t assume reusability, progress reporting, etc. If you take a look to other implementations of a future (like boost::future, folly::future or std::experimental::future), none of them has this “extra” functionality similar to QFuture, none of them represents a set of results as QFuture does. This may be confusing for people who are expecting QFuture to be a typical future they are used to, and I actually saw some complains about that. Best regards, Sona From: Иван Комиссаров mailto:abba...@gmail.com>> Sent: Saturday, February 1, 2020 1:56 PM To: Sona Kurazyan mailto:sona.kuraz...@qt.io>> Cc: development@qt-project.org<mailto:development@qt-project.org> Subject: Re: [Development] Make a decision for asynchronous APIs Can you please elaborate the difference? 31 янв. 2020 г., в 17:24, Sona Kurazyan mailto:sona.kuraz...@qt.io>> написал(а): 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? ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Make a decision for asynchronous APIs
Ah, thanks. Now I see why I am confused - in my understanding Task is something more similar to std::function in terms that it it something that can be stored and executed (somehow) later. E.g. instead of doing something like auto future = QtConcurrent::run(foo, value1, value2); We do auto task = QtTasks::createTask(foo, value1, value2); // do stuff auto future = QtConcurrent::run(task); I do not see why cancellation/progress reporting makes QFuture «not a future» - it’s simply an interface to an async execution. Stored function call is something different, on the other hand. Can you also elaborate what do you mean by «reusability»? Ability to do something like future.restart(); ? > 1 февр. 2020 г., в 14:44, Sona Kurazyan написал(а): > > In my understanding a future represents a single result of a computation > which will be available sometime in future, it doesn’t assume reusability, > progress reporting, etc. If you take a look to other implementations of a > future (like boost::future, folly::future or std::experimental::future), none > of them has this “extra” functionality similar to QFuture, none of them > represents a set of results as QFuture does. This may be confusing for people > who are expecting QFuture to be a typical future they are used to, and I > actually saw some complains about that. > > Best regards, > Sona > > > From: Иван Комиссаров > Sent: Saturday, February 1, 2020 1:56 PM > To: Sona Kurazyan > Cc: development@qt-project.org > Subject: Re: [Development] Make a decision for asynchronous APIs > > Can you please elaborate the difference? > > > 31 янв. 2020 г., в 17:24, Sona Kurazyan <mailto:sona.kuraz...@qt.io>> написал(а): > > 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? ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Make a decision for asynchronous APIs
Den lör 1 feb. 2020 kl 14:48 skrev Sona Kurazyan : > > > > > -Original Message- > > From: Elvis Stansvik > > Sent: Friday, January 31, 2020 7:20 PM > > To: Sona Kurazyan > > Cc: development@qt-project.org > > Subject: Re: [Development] Make a decision for asynchronous APIs > > > > > > > > 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? > > Yes, that would be my preference as well. Alright, thanks. That sounds reasonable to me too. Elvis > > Best regards, > Sona ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Make a decision for asynchronous APIs
> -Original Message- > From: Elvis Stansvik > Sent: Friday, January 31, 2020 7:20 PM > To: Sona Kurazyan > Cc: development@qt-project.org > Subject: Re: [Development] Make a decision for asynchronous APIs > > > > > 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? Yes, that would be my preference as well. Best regards, Sona ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Make a decision for asynchronous APIs
In my understanding a future represents a single result of a computation which will be available sometime in future, it doesn’t assume reusability, progress reporting, etc. If you take a look to other implementations of a future (like boost::future, folly::future or std::experimental::future), none of them has this “extra” functionality similar to QFuture, none of them represents a set of results as QFuture does. This may be confusing for people who are expecting QFuture to be a typical future they are used to, and I actually saw some complains about that. Best regards, Sona From: Иван Комиссаров Sent: Saturday, February 1, 2020 1:56 PM To: Sona Kurazyan Cc: development@qt-project.org Subject: Re: [Development] Make a decision for asynchronous APIs Can you please elaborate the difference? 31 янв. 2020 г., в 17:24, Sona Kurazyan mailto:sona.kuraz...@qt.io>> написал(а): 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? ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Make a decision for asynchronous APIs
So what you are suggesting, is basically the current QFuture (combined with QFutureWtacher), but with "trimmed" runtime controls? And if we do that, we also need to have QTask for the cases where the runtime controls are needed (for example QtConcurrent, qtcreator). Best regards, Sona > -Original Message- > From: Allan Sandfeld Jensen > Sent: Friday, January 31, 2020 7:40 PM > To: development@qt-project.org > Cc: Sona Kurazyan > Subject: Re: [Development] Make a decision for asynchronous APIs > > On Freitag, 31. Januar 2020 17:24:20 CET Sona Kurazyan wrote: > > 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? > > > As I have expressed earlier I would love the simplified QFuture, just a > something that can hold the result of an async function, but no runtime > controls. Just ways to test if the result is ready and to be notified when it > is, > like with a waitForResult blocking method and a signal emitter of some kind. > > I think there are many cases where such an API would be useful. > > Best regards > 'Allan > ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Make a decision for asynchronous APIs
Can you please elaborate the difference? > 31 янв. 2020 г., в 17:24, Sona Kurazyan написал(а): > > 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? > ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Make a decision for asynchronous APIs
On Freitag, 31. Januar 2020 17:24:20 CET Sona Kurazyan wrote: > 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? > As I have expressed earlier I would love the simplified QFuture, just a something that can hold the result of an async function, but no runtime controls. Just ways to test if the result is ready and to be notified when it is, like with a waitForResult blocking method and a signal emitter of some kind. I think there are many cases where such an API would be useful. Best regards 'Allan ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Make a decision for asynchronous APIs
Den fre 31 jan. 2020 kl 17:25 skrev Sona Kurazyan : > > 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 on behalf of Karsten > Heimrich > Sent: Thursday, December 19, 2019 2:12 PM > To: 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
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 on behalf of Karsten Heimrich Sent: Thursday, December 19, 2019 2:12 PM To: 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] 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
