niedz., 28 cze 2026 o 21:51 Vinnie Falco <vinnie.falco@gmail.com> napisał(a):
On Sun, Jun 28, 2026 at 12:00 PM Andrzej Krzemienski <akrzemi1@gmail.com> wrote:
Term "awaitable" is never defined
Hmm... you are right! I thought awaitable was a C++ concept. It seems it is not. There is no formal name for the awaitable/awaiter (Confidence: medium, I googled it).
Anyway "awaitable" in this context means the type with await_ready, await_suspend, await_resume, required in [expr.await].
So, my type somehow automatically passes the environment down, but my coroutines cannot access it? So how can my coroutines respond to a stop request?
If you are using capy::task then the docs explain how to get the stop token.
If you are writing your own task type, you fall in the category of "framework author", and then you have to design a mechanism to get the stop token.
I can see how the environment is propagated *from* Capy types to my types. But I cannot see how my types propagate the environment automatically to other types.
Hmm... yes, you are right. P4003 explains it but very briefly "the caller's await_transform injects the environment as a pointer parameter." This is not sufficient.
If so, can I make my coroutines not lazy? That is, not suspend in the
initial_suspend point?
Yes and that's how synchronous I/O works.
But this seems to clash with how the environment is propagated. It is my understanding that the stop token and the executor are propagated to the user coroutine's promise upon the first suspension. So, in my eager coroutine, if I want to respond to the stop request, I do not have the stop token yet. Or am I missing something? Regards, &rzej;
Thanks