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

• 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