Re: [Capy] Review Note
Andrzej Krzemienski via Boost <[email protected]> Tue, 30 Jun 2026 07:48:48 +0200
| Newsgroups | gmane.comp.lib.boost.devel |
|---|---|
| Message-ID | <CAOenAXhjsTGvcgDpU2MokjACPBhWDo4S0fuRHK38w3Nzy4DbCg@mail.gmail.com> |
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/