Known Issues

v2.1.0

This list follows the current stdexec implementation. Historical async-simple issues are kept in the v1 archive and are not current API guidance.

Known Limitations

No General Cancellation Mechanism

There is no general async cancellation. Cancelling a Stream subscription only stops new events from being delivered; the C++ side continues running and silently drops subsequent add() calls.

Codegen Is Not a Build Step

Code generation must be run manually after API header changes. The Native Assets hook only handles compilation and linking; it does not regenerate code.

Type Aliases Are Not Supported

codegen cannot parse using Foo = ... or typedef .... Use the actual type directly in headers and write out the full namespace.

Opaque Class Limitations

• Cannot be shared across Isolates
• Inheritance, virtual functions, and method overloading are not supported
• Field access requires hand-written getter/setter methods

Common Pitfalls

Danger

Never block the io_context thread.

• Blocking work must use spawn_blocking or be posted to the thread_pool
• set_pool_threads() must be called before Runtime::start()
• The Runtime uses one io runner by default; configure ioThreads before startup when multiple runners are needed, and synchronize shared state accordingly
• Multiple io runners do not make blocking waits safe: raw stdexec::sync_wait occupies its runner until completion, and blocks the whole scheduler if every runner waits for work on that scheduler; dcb::sync_wait rejects io runners
• Generated code must be regenerated manually by running dcb_gen_tool generate
• Headers should contain only declarations; data classes and opaque classes must be defined inside the scanned headers
• DartFn::operator() is async only; for blocking calls use dcb::sync_wait(...) from a worker or external thread, and never do so on the io thread