wt., 30 cze 2026 o 17:41 Michael Vandeberg <michael@cppalliance.org> napisał(a):
Yes, if stored on the awaitable, env is accessible and null (or garbage) in await_ready(). However, this is a property of the C++20 awaitable contract rather than of the two-argument signature. await_ready() takes no arguments for any awaitable, and no standard mechanism can inject context into it. The protocol delivers env at the only customization point the language gives a parameter slot.
I am not sure I get this explanation. You say " this is a property of the C++20 awaitable contract". It is also the property of the same contract that you cannot pass the allocator to the coroutine before the coroutine frame is allocated. Yet, Capy overcomes this limitation via the thread_local cache. Maybe you could use the same trick for the stop_token? I suppose there is a reason not to do it this way. It is clearly an engineering trade-off, undocumented. The docs should have a note that eager awaitables satisfy IoAwaitable, and that there is a footgun in that case. Regards, &rzej;
Any env dependent eager behavior belongs at the top of await_suspend() which can return the handle or false to resume immediately at no real suspension cost.
await_ready() should be used only for the awaitable's own state, not the environment's state.
On Mon, Jun 29, 2026 at 11:51 PM Andrzej Krzemienski via Boost < boost@lists.boost.org> wrote:
niedz., 28 cze 2026 o 22:18 Andrzej Krzemienski <akrzemi1@gmail.com> napisał(a):
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?
Can you respond to this?
It looks like "I/O library author"-tier users when defining their own "eager" IoAwaitable, will not have access to the awaiter's stop token and executor in the eager part. Worse still, syntactically they will be accessible, so any attempts to use them will compile but trigger UB (or a moral equivalent thereof).
Regards, &rzej;
Regards, &rzej;
Thanks
_______________________________________________ Boost mailing list -- boost@lists.boost.org To unsubscribe send an email to boost-leave@lists.boost.org https://lists.boost.org/mailman3/lists/boost.lists.boost.org/ Archived at: https://lists.boost.org/archives/list/boost@lists.boost.org/message/MPBX3ATC...