Re: [Capy] Review Note

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.

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 <
[email protected]> wrote:

> niedz., 28 cze 2026 o 22:18 Andrzej Krzemienski <[email protected]>
> napisał(a):
>
> >
> >
> > niedz., 28 cze 2026 o 21:51 Vinnie Falco <[email protected]>
> > napisał(a):
> >
> >> On Sun, Jun 28, 2026 at 12:00 PM Andrzej Krzemienski <
> [email protected]>
> >> 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 -- [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/MPBX3ATCDG6Y5PPG75RUIAU446H3GDGS/
>
_______________________________________________
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/O4ISR4MPYQFCPQVFZHJEQ3TV55C6MGCE/