Re: Capy Review

Rainer Deyke wrote:
> This isn't about Capy vs TooManyCooks.  This is Capy vs an entire world of C++
> coroutine code that can interact with each other more or less seamlessly.

That's very far from the truth today, and it's probably never going to be true
unless something like Capy is adopted as standard.

Everyone that tries to write a coroutine library starts out with this
interoperability goal in mind, and then gradually arrives at the conclusion
that it's unattainable, and Capy followed the same path.

The problem is that there needs to be a standard way to propagate important
state to the foreign coroutine, so that the foreign coroutine can at least
propagate that same state back to you if it co_awaits one of yours.

That state in Capy consists of the executor, the stop token, and the allocator.
And while you can argue that the allocator is optional (but it isn't in practice),
the other two most certainly are not.

If every co_await can switch your coroutine to some arbitrary executor,
the model becomes wildly impractical and everyone using coroutines in
practice eventually arrives at the conclusion that coroutines need to be
resumed on the executor they started on (apart from obvious explicit
constructs that switch, e.g. `co_await resume_on( ex );`.)


_______________________________________________
Boost mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://lists.boost.org/mailman3/lists/boost.lists.boost.org/
Archived at: https://lists.boost.org/archives/list/[email protected]/message/PXNOXGTVIMBTAZ5ZW5MNILTHWPJ73DZL/