-
Notifications
You must be signed in to change notification settings - Fork 9
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Discussion for Understanding Operator co_await #2
Comments
Very good article, thanks for sharing. |
This is a great article! Thank you! |
Really good article, thanks a lot. I'm excited about the next one on the |
I'm |
It looks as if coroutines were removed from the proposed standard? I can't find any reference to them on cppreference |
Coroutines have not yet been adopted into the C++ draft standard, but I'm still hopeful they will be for C++20 :) See this cppreference page for the reference to the latest version of the Coroutines TS: |
How I can compile examples? |
@ddosoff You can use Compiler Explorer to compile cppcoro examples. You just need to enable the cppcoro library in the “Libraries” drop down. Alternatively check out the cppcoro repository locally and follow the build instructions in thr Readme. |
Interesting to compare the amount of code (and complexity) in the C++ version of an async event and the C# one. Why does it have to be so complex (linked lists, atomic types)? |
Hi Lewiss, thanks again for the great article. Based on some examples and n4736, await_suspend could return not only void and bool but also coroutine_handle as well. When could it be useful? Also then how would compiler translation look like with it? |
@insoulity the possibility to have await_suspend return coroutine_handle has been introduced recently by paper p0913. I'll suggest you read the paper (it's very short). |
@iaanus Thanks for the reference. FYI one example with such an awaiter type I saw before was Nano-coroutine example by Gor's last year Cppcon. |
The C# implementation will typically make use of the The implementation for C++ performs no heap allocation directly - it uses storage space from the coroutine frame and stitches these together into a linked list. |
@insoulity The compiler translation for the symmetric-transfer version of
The really interesting thing about this variant is that the compiler is performs a guaranteed tail-call to the See the latest version of I've been meaning to write up more detail about the benefits of symmetric-transfer and hope to do so soon. |
Hello Lewis, Thanks a lot for your time and articles |
Should
|
Hello @lewissbaker ! Is it right that async_manual_reset_event resumes all awaiting consumers on the single thread? So, there were many awaiting threads but they will wake up on the single thread? |
@subbota-a Yes, the implementation of A future enhancement might require the awaiting coroutine to provide a scheduler that will be used to schedule the resumption of the coroutine at a later time rather than resuming it inline inside the call to |
Hello @lewissbaker, I was wondering if this portion of the article is accurate?
as this would suggest that if get_awaitable and/or get_awaiter produced values, their lifetimes would be limited to the scope of this. clang 10 currently doesn't function like this, and I would like to file a bug with them, as it's very beneficial to have an awaiter's lifetime effectively hidden from the caller |
@martinbonaciugome Yes, I think technically if get_awaitable() and/or get_awaiter() returns a prvalue then the lifetime of those objects will extend to the end of the full-expression, rather than their lifetimes being limited to the scope of the The |
Thanks for the quick reply. That's a shame, as these objects are completely hidden and are just plumbing, yet will cause a lot more code and inefficiencies to handle coroutine destruction during suspension, and will bloat the coroutine frame substantially if co_await is used in subexpressions for long running deep coroutines like UI. |
Thanks for the series. In the code skeleton in section "Awaiting the Awaiter" Should the Thanks |
Nit typo report: In the ASCII graph in section "Synchronisation-free async code": |
Again about this section, bit of a noob question here...
What exactly is the purpose of the static_cast<decltype(awaitable)> expressions? Is it to turn possible named rvalue references back into rvalues instead of them being copied? How is this functionally different from using std::forward? |
For the following section:
Shouldn't it be std::memory_order_release? You need to release any writes that occured prior to calling reset() to any thread that just checks the status of the event with is_set which uses std::memory_order_acquire. edit: I see in the github source you've changed reset() to use relaxed instead. This makes more sense than acquire, but I still think it should be release. |
This article was published on 2017 and the spec for coroutine was released on 2020. Just wondering if this article, and other (coroutine) articles on your blog, are still conforming to the 2020 spec? 🤔 It'd be great if you put a comment/disclaimer (on the top) mentioning the status of the articles, just to avoid such confusions, or mistakenly misleading the C++ programmers (in case the articles are not conforming anymore). 😄 |
Hi Lewis,
Thanks! |
These two are equivalent. I sometimes write |
Hi lewissbaker, I noticed that a friend class declaration of Your source on godbolt declared it though(line 49). |
Hi Lewis, Great article and series! Thanks! 🙏 A minor comment: |
Godbolt link expired since it uses clang trunk, I think this is ok update, |
Please add comments here to discuss or provide feedback on https://lewissbaker.github.io/2017/11/17/understanding-operator-co-await
The text was updated successfully, but these errors were encountered: