QtCS2024 QFuture/QPromise: Difference between revisions
Jump to navigation
Jump to search
(Created page with "==Session Summary== ==Session Owners== ==Notes== Category:QtCS2024") |
(Added discussion points and research) |
||
Line 1: | Line 1: | ||
==Session Summary== | ==Session Summary== | ||
In the scope of Qt OPC UA, which is inherently asynchronous, we’re investigating the use of QFuture/QPromise to make the APIs more convenient. | |||
This discussion session is about setting standards for QFuture/QPromise-based APIs throughout Qt to ensure consistent naming and error handling before their use within Qt expands further. | |||
==Session Owners== | ==Session Owners== | ||
Kai Uwe Broulik <kai.uwe.broulik@basyskom.com> | |||
==Notes== | ==Notes== | ||
=== Discussion === | |||
https://codereview.qt-project.org/c/qt/qtopcua/+/570819 | |||
* Naming, connectToHostAsync, connectToHost2, … | |||
** particularly when retrofitting | |||
* Error handling | |||
** canceled future, exception? | |||
* throw vs setException | |||
** what if I have a function that I want to be usable both from a continuation and not | |||
=== Co-Routines === | |||
The elephant in the room ;) | |||
How do we avoid yet another “new style API” when Co-routines come around? Can we make existing QFuture awaitable? | |||
https://qcoro.dvratil.cz/ | |||
=== Other ideas === | |||
* Async QMimeData / Clipboard | |||
* Async file IO | |||
** In general many Qt APIs are convenient and innocent-looking and then block your program because it’s all synchronous | |||
=== Precedent (pretty much exhaustive) === | |||
==== qtbase ==== | |||
* runOnAndroidMainThread | |||
* requestPermission in QtAndroidPrivate »Requests the permission and returns a QFuture representing the result of the request.« Does this mean it gets fulfilled and cancelled when not? | |||
==== qtdeclarative ==== | |||
* QQmlXmlListModelQueryRunnable::future | |||
==== qtmultimedia ==== | |||
* QFFmpegMediaPlayer::m_loadMedia | |||
* QGstreamerImageCapture::m_pendingFutures from saveBufferToImage | |||
* QQnxImageCapture::decodeFrame | |||
==== qttools ==== | |||
* QHelpEngineCore::requestContentForCurrentFilter with QFuture<std::shared_ptr<QHelpContentItem>> | |||
[[Category:QtCS2024]] | [[Category:QtCS2024]] |
Revision as of 08:10, 5 September 2024
Session Summary
In the scope of Qt OPC UA, which is inherently asynchronous, we’re investigating the use of QFuture/QPromise to make the APIs more convenient.
This discussion session is about setting standards for QFuture/QPromise-based APIs throughout Qt to ensure consistent naming and error handling before their use within Qt expands further.
Session Owners
Kai Uwe Broulik <kai.uwe.broulik@basyskom.com>
Notes
Discussion
https://codereview.qt-project.org/c/qt/qtopcua/+/570819
- Naming, connectToHostAsync, connectToHost2, …
- particularly when retrofitting
- Error handling
- canceled future, exception?
- throw vs setException
- what if I have a function that I want to be usable both from a continuation and not
Co-Routines
The elephant in the room ;)
How do we avoid yet another “new style API” when Co-routines come around? Can we make existing QFuture awaitable?
Other ideas
- Async QMimeData / Clipboard
- Async file IO
- In general many Qt APIs are convenient and innocent-looking and then block your program because it’s all synchronous
Precedent (pretty much exhaustive)
qtbase
- runOnAndroidMainThread
- requestPermission in QtAndroidPrivate »Requests the permission and returns a QFuture representing the result of the request.« Does this mean it gets fulfilled and cancelled when not?
qtdeclarative
- QQmlXmlListModelQueryRunnable::future
qtmultimedia
- QFFmpegMediaPlayer::m_loadMedia
- QGstreamerImageCapture::m_pendingFutures from saveBufferToImage
- QQnxImageCapture::decodeFrame
qttools
- QHelpEngineCore::requestContentForCurrentFilter with QFuture<std::shared_ptr<QHelpContentItem>>