4 ms·
I've used C++ coroutines (with io_uring). They are really useful in this case and allows one to write code like one would with the simple blocking API. And from
by tobias3 6y ago
I've used C++ coroutines (with io_uring). They are really useful in this case and allows one to write code like one would with the simple blocking API. And from what I've read they are better than Rusts coroutines for this use case (and for the yield use case they aren't good).
It adds an additional foot-gun w.r.t. to e.g. by-reference parameters to functions and their lifetime. The function parameter might not be alive anymore after a "co_await" and it doesn't require any capture (like lambda) or has any hint about this being the case.
Then, the tooling isn't there yet (other than the missing standard library). Gdb doesn't show correct lines and can't print local variables when in coroutines. If there is a deadlock one can't see the suspended coroutine (and its call stack) holding the lock, etc.. Back to printf debugging...
- tijsvd 6y ago> And from what I've read they are better than Rusts coroutines for this use case Reference please? In what sense are they better, and what makes them better?
- pornel 6y agoRust's Futures don't have asynchronous destructors (I don't know if coroutines do). When a Future is aborted early, it's destroyed immediately with no remorse. This means it can't simply offer its own buffers to the kernel, because the kernel could write back after the Future has been freed. An API contract that includes "just be careful not to do the stupid thing" is not good enough by Rust's standards, so the only way to guarantee safety would be to have Future's destructor wait synchronously until the I/O operation is cancelled on the kernel side, but that's inelegant in an async context.
- drran 6y agoIsn't Future lifetime must be tied to I/O operation, so Future will not outlive I/O operation? Can you post an example, please?
- deleted 6y ago[deleted]
- Matthias247 6y agoC++ coroutines for async functions (returning std::task) seem to have completion semantics (are not randomly interruptible). See eg the APIs in cppcoro. However that is not a general property of c++ coroutines. The generator style coroutines also seem randomly cancellable