QtCS2024 QFuture/QPromise
Jump to navigation
Jump to search
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>>