View source for QtCS25 - Async 1:1 APIs

==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==
[[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]]