search

GorNishanov / coroutines-ts

20 stars 2 forks source link

Can we resume() from a coro which is suspended in the final_suspend() point? #11

Closed JCYang closed 7 years ago

JCYang commented 7 years ago

There's no wording in N4649 stated this clearly, Currently with the MSVC 2017 implementation, the answer is no, compiler does not check this at compile time but DO throw a range check invalid range exception at runtime. What should be expected from reading N4649, final_suspend should be just yet-another-suspension-point, why shouldn't we resume() from it and let the coro flow off the end? Yes, for the current implementation, I know we should call destroy() at this point. Then the program will be ok. I'd like to know the reason and we definitely need some wording in the TS to clarify this.

JCYang commented 7 years ago

Sorry for bring up this issue, I just find that it's already stated in 18.11.2.5. But I'd still like to know why? What's the reason behind this undefined behavior?

GorNishanov commented 7 years ago

Two reasons: 1) allows compilers to generate a trap code to help you with debugging if you accidentally resume the coroutine which is at final suspend point (in a debug / safe mode) 2) allows compilers to generate more efficient code by eliminating the final suspend point from a "resume" portion of the coroutine. (in optimized code)

Here is a presentation on some of the details of coroutine code generation in clang/llvm: https://www.youtube.com/watch?v=Ztr8QvMhqmQ

JCYang commented 7 years ago

Thank you for the explanation, Gor. Will drop you email for further clang implementation status.