QtCS25 - Async 1:1 APIs: Difference between revisions
Jump to navigation
Jump to search
(Created page with "==Session Summary== ''Lorem ipsum dolor sit amet, consetetur sadipscing elitr, sed diam nonumy eirmod tempor invidunt ut labore et dolore magna aliquyam erat, sed diam voluptua. At vero eos et accusam et justo duo dolores et ea rebum.'' ==Session Owners== ''Lorem Ipsum'' ''Consetetur Sadipscing'' ==Notes== ''Lorem ipsum dolor sit amet, consetetur sadipscing elitr, sed diam nonumy eirmod tempor invidunt ut labore et dolore magna aliquyam erat, sed diam voluptua. At v...") |
Ivan.solovev (talk | contribs) (→Notes) |
||
| (2 intermediate revisions by 2 users not shown) | |||
| Line 1: | Line 1: | ||
==Session Summary== | ==Session Summary== | ||
* informed about the current state/PoCs | |||
* designing asynchronous APIs as proposed seems to make sense | |||
* follow-up on Friday hacking day to experiment with other use cases | |||
==Session Owners== | ==Session Owners== | ||
Presenters: | |||
* Ivan, Mårten (async I/O proposal based on QFile) | |||
* Ville (QtStdExec recap) | |||
Notes: | |||
* Volker | |||
==Notes== | ==Notes== | ||
'' | [[File:Async APIs QtCS2025.pdf|thumb]] | ||
* Problem | |||
** QFile does not emit the QIODevice signals | |||
** but I/O should nowadays be asynchronous | |||
** also, WebAssembly doesn't allow a blocking loop | |||
* With C++17 | |||
** QFileV2 that returns a Q*Operation object from async operations | |||
** Operations start when attaching a callback | |||
* With C++20 | |||
** use coroutines | |||
** a natural evolution of a call-back based API (even BC/SC, adding co_await operator that returns a type implementing coroutine protocol) | |||
* With C++26 | |||
** use senders/receivers (PoC done with Nvidia's libexec and Ville's QtStdExec) | |||
** also BC with C++17/20 approaches | |||
* QtStdExec recap | |||
** S&R provides higher-level abstractions for concurrency | |||
** properties: avoid data sharing, thus avoids mutexes, atomics -> no race conditions and deadlocks | |||
** QtStdExec: QThread is a scheduler, any signal can be a sender (in S&R context), qEventLoopWait helper for "await" | |||
** however, in S&R senders are 1:1, while Qt signals can have multiple receivers (so moving data is not possible) | |||
** requires C++20 (reference implementation uses concepts, no luck in making it work with C++17) | |||
** aim is to provide an optional module in 6.12, with a 3rd party library dependency | |||
** next step would be an optional module using the C++26 facilities | |||
** when(ever) we require C++26: non-optional module | |||
* possible approaches for non-optional APIs in the meantime | |||
** have a subset of S&R that can "run this workload on that thread, pipe results there" | |||
** error handling? | |||
* Discussion | |||
** QtConcurrent, QFuture | |||
*** too heavy, not easy enough to use, adds complexity | |||
*** might be possible to make this more convenient | |||
** error handling | |||
*** in order to be able to use co_await, we need a type that is like std::expected | |||
** debugging asynchronous/coroutine stuff | |||
*** very hard with currently available debuggers (msvc in bad; gdb seems a bit better) | |||
*** sender/receiver pipeline construction is lazy (as everything is suspended until launched) | |||
*** not a stopper (things might improve), but have to be aware of that and train people | |||
** in-depth asynchronous behaviour | |||
*** Functions using QFile to return a loaded value (e.g. a QImage) also need to be made async | |||
[[Category:QtCS2025]] | |||
Latest revision as of 14:17, 8 May 2025
Session Summary
- informed about the current state/PoCs
- designing asynchronous APIs as proposed seems to make sense
- follow-up on Friday hacking day to experiment with other use cases
Session Owners
Presenters:
- Ivan, Mårten (async I/O proposal based on QFile)
- Ville (QtStdExec recap)
Notes:
- Volker
Notes
- Problem
- QFile does not emit the QIODevice signals
- but I/O should nowadays be asynchronous
- also, WebAssembly doesn't allow a blocking loop
- With C++17
- QFileV2 that returns a Q*Operation object from async operations
- Operations start when attaching a callback
- With C++20
- use coroutines
- a natural evolution of a call-back based API (even BC/SC, adding co_await operator that returns a type implementing coroutine protocol)
- With C++26
- use senders/receivers (PoC done with Nvidia's libexec and Ville's QtStdExec)
- also BC with C++17/20 approaches
- QtStdExec recap
- S&R provides higher-level abstractions for concurrency
- properties: avoid data sharing, thus avoids mutexes, atomics -> no race conditions and deadlocks
- QtStdExec: QThread is a scheduler, any signal can be a sender (in S&R context), qEventLoopWait helper for "await"
- however, in S&R senders are 1:1, while Qt signals can have multiple receivers (so moving data is not possible)
- requires C++20 (reference implementation uses concepts, no luck in making it work with C++17)
- aim is to provide an optional module in 6.12, with a 3rd party library dependency
- next step would be an optional module using the C++26 facilities
- when(ever) we require C++26: non-optional module
- possible approaches for non-optional APIs in the meantime
- have a subset of S&R that can "run this workload on that thread, pipe results there"
- error handling?
- Discussion
- QtConcurrent, QFuture
- too heavy, not easy enough to use, adds complexity
- might be possible to make this more convenient
- QtConcurrent, QFuture
- error handling
- in order to be able to use co_await, we need a type that is like std::expected
- error handling
- debugging asynchronous/coroutine stuff
- very hard with currently available debuggers (msvc in bad; gdb seems a bit better)
- sender/receiver pipeline construction is lazy (as everything is suspended until launched)
- not a stopper (things might improve), but have to be aware of that and train people
- debugging asynchronous/coroutine stuff
- in-depth asynchronous behaviour
- Functions using QFile to return a loaded value (e.g. a QImage) also need to be made async
- in-depth asynchronous behaviour