Re: [Capy] Review Note

wt., 30 cze 2026 o 17:41 Michael Vandeberg <[email protected]>
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 <
> [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/7NGET4RK3EMBMKVXCL65BCAGZX7BNWGB/