luncliff/coroutine

C++ 20 Coroutines in Action (Helpers + Test Code Examples)

coroutine

C++ 20 Coroutines in Action

Purpose of this repository

• Help understanding of the C++ Coroutines
• Provide meaningful design example with the feature

In that perspective, the library will be maintained as small as possible. Have fun with them. And try your own coroutines! If you want some tool support, please let me know. I'm willing to learn about it.

If you are looking for another materials, visit the MattPD's collection!

• Start with the GitHub Pages :)
  You will visit the test/ and interface/ folder while reading the docs.
• This repository has some custom(and partial) implementation for the C++ Coroutines in the <coroutine/frame.h>.
  It can be activated with macro USE_PORTABLE_COROUTINE_HANDLE

Toolchain Support

Currently using CMake to generate buildsystem files with the following compilers.

• msvc v142+
• clang-cl 13+
• clang 12+
• AppleClang 12+
• gcc 10.0+

How To

Setup

git clone "https://github.com/luncliff/coroutine"
Push-Location coroutine
  # ...
Pop-Location

Test

Exploring test(example) codes will be helpful. The library uses CTest for its test. AppVeyor & Travis CI build log will show the execution of them.

coroutine's Issues

Better worker thread for POSIX

Note

1.3 version uses aggressive polling strategy. Need enhancement for ease of care and thread management.

More pretty documentation

Apply mkdocs for wiki / github pages

References

• https://www.mkdocs.org
• https://squidfunk.github.io/mkdocs-material/extensions/codehilite/
• https://www.mkdocs.org/user-guide/deploying-your-docs

Lazy thread registration

Note

Since this library intends to be used in a DLL form, it needs to support thread registration of already existing threads. (Lazy registration)

For Win32

The code in 51b3474 working well.
For very first message might have ordering problem(Not in FIFO manner), but the case can be handled by user. This is because APC can't be scheduled manually.

For POSIX

For the feature, 2 requirement must be fulfilled.

• Lookup of thread:
  There must be a way to know if the thread with given ID exists
• Trigger a specific operation:
  Something like APC in Win32. Signal handler will be enough for this but can't be used if those threads already using their own handlers.

Unless the user doesn't trigger registration of each thread, the library can't guarantee their registration.

Alternative: Global Queue

Store messages into shared queue and fetch them later. This can overrun resource limitation. And the code for distributing those messages can be complex than expectation

Alternative: Scheduling

… work with background thread? ...

Related Issue

• #10

Code coverage generation

Note

This issue is about generating code coverage of the library & test executable

Visual Studio Testing Tools

• vstest, CodeCoverage

Sonar code analysis failes for latest C++ syntax. Seems like this is the reason for low coverage in SonarCloud. Coverage report in Azure Pipelines is about 78%

Issue: coveragexml generation

• Commit 42a7235
• Build: Azure Pipelines Build 191

Hotfix applied with Azure Pipelines build 204

# ...
sonar.sourceEncoding=UTF-8 
sonar.cfamily.build-wrapper-output=bw-output 

# this line was originally **/*.coveragexml to collect all related files
sonar.cfamily.vscoveragexml.reportsPath=**/luncliff-coroutine-visual-studio.coveragexml
# ...

And coverage to xml generation script is like the following

# Path to Codecoverage.exe
$env:Path += ";C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\Team Tools\Dynamic Code Coverage Tools"

# Acquire coverage file and generate temporary coverage file
$coverage_file = Get-ChildItem -Recurse *.coverage;
Write-Host $coverage_file
$temp_coverage_xml_filepath  = "./TestResults/coverage-report.xml"
CodeCoverage.exe analyze /output:$temp_coverage_xml_filepath $coverage_file

# Display result files of CodeCoverage.exe
Tree ./TestResults /F

# Filter lines with invalid line number 
#   and Create a new coverage xml
$final_coverage_xml_filepath = "./TestResults/luncliff-coroutine-visual-studio.coveragexml"
$xml_lines = Get-Content $temp_coverage_xml_filepath
foreach($text in $xml_lines){
    if($text -match 15732480){
        continue;
    }
    else {
       Add-Content $final_coverage_xml_filepath $text;
    }
}

# Check if the coveragexml is in right place
Tree ./TestResults /F

# Display information of a new coverage xml
Get-ChildItem $final_coverage_xml_filepath
Get-Content   $final_coverage_xml_filepath

LLVM Coverage

Unfortunately, Clang makes a crash for the build with --coverage option. Preparing for detailed reproduction of the crash and reporting to LLVM Bugzilla. The crash both occurs for clang-6 and AppleClang

TBA

Need more return types

Considering combination of initial_suspend/final_suspend, we need at least 4 return types.

Idea

I'd like to reuse existing types for coroutines' return whenever possible.

• How about using *_frame_t for controlled destruction?
  (final suspend returns suspend_always)
• ...?

std::nullptr_t/void

Something like null_frame_t. (previously no_return)

• initial: suspend_never
• final: suspend_never

#include <coroutine/return.h>

auto impl() -> std::nullptr_t {
    co_await std::suspend_never{};
}
void usage(){
    impl();
}

Or if compiler allows, void can be an option. (GCC-10 requires the type must be class)

passive_frame_t

Usually for manual start(initiate) / cleanup(destroy) of the frame.

• initial: suspend_always
• final: suspend_always

#include <coroutine/return.h>

[[nodiscard]] auto impl() -> coro::passive_frame_t {
    co_await std::suspend_never{};
}
void usage(){
    std::coroutine_handle<void> rh = impl();
    rh.resume(); // resume at the initial suspend point
    // ...
    if(rh.done()) // reserved after final suspend point
        rh.destroy();
}

std::packaged_task<R(P, ...)>

• https://en.cppreference.com/w/cpp/thread/packaged_task/packaged_task

Lazy execution of the coroutine, especially to allow control of execution cost. (For future support of Concurrency TS or Executor TS)

• initial: suspend_always
• final: suspend_never

#include <coroutine/return.h>

[[nodiscard]] auto impl(int a, int b) -> std::packaged_task<int(void)> {
    co_await std::suspend_never{};
    co_return a + b;
}
void usage(){
    auto task = impl(1, 1);
    auto f = task.get_future();
    task();
    assert(f.get() == 2);
}

Concerns

std::packaged_task<R(P, ...)> requires std::future<R> support.
It is highly possible to be heavy more than necessary.

frame_t

Controlled destruction of the coroutine frame.

• initial: suspend_never
• final: suspend_always

#include <coroutine/return.h>

[[nodiscard]] auto impl() -> coro::frame_t {
    co_await std::suspend_never{};
}
void usage(){
    std::coroutine_handle<void> rh = impl();
    if(rh.done())
        rh.destroy();
}

yield immediate value?

coro::enumerable<int> test() {
    co_yield 1;
}

test.cpp:5:14: error: non-const lvalue reference to type 'coro::enumerable<int>::value_type' (aka 'int') cannot bind to a temporary of type 'int'
    co_yield 1;
             ^
../interface/coroutine/yield.hpp:83:36: note: passing argument to parameter 'ref' here
        auto yield_value(reference ref) noexcept {

Guide for mutex lock failure

Releated Items

• Test Failure: Travis CI
• Test Failure: AppVeyor

System

• Ubuntu 1804, 1604

Note

This was a suggestion. See #9 for later decision

Since channel<T> uses lockable, user need a handling guide(or example at least) for lock operation failure.

Test codes also need to updated for this issue

Lockable Requirements

• Recursive?
• ...

test for sequence(async generator) fails on clang release build

Note

• Detected: f9d9b7f
• Work start: 28eeba3

Build log from AppVeyor

Goals

• Fix the test failures in release build
• If that's too hard, make sure of the reason

Related Issues

• #3 (channel test code crash with clang release build)
• #31 (catch2 test crashed on the sequence's test)

References

• https://bugs.llvm.org/show_bug.cgi?id=40656
• https://www.reddit.com/r/cpp/comments/aoad7l/coroutine_allocation_elision_broken_in_clang_7

catch2 reports "corrupted double-linked list"

Working branch: dev/yield

The issue is related to sequence<T>.

Note

• https://travis-ci.org/luncliff/coroutine/jobs/528460139
• https://travis-ci.org/luncliff/coroutine/jobs/528496819

Detected while fixing issue #30. Reviewing the test cases with WSL.
However, some separated execution doesn't report the failure.

Going to monitor carefully until the condition becomes clear.
Seems like this issue is related to custom implementation in <coroutine/frame.h>. If so, this issue will be treated with the highest concerns.

---

Can't reproduce the issue with WSL. If the native ubuntu can't do that either, I have to find another way to track this issue in Travis CI container.

Review: N4820

Related Issues

• #22 (open-std review)
• #34 (documentation of the repository)

Note

Since March 2019, the standard document reference was fixed to N4736.
The latest one is N4820, need a quick review for it.

References

• https://github.com/cplusplus/draft
• http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/
• http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/n4820.pdf
• http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/n4736.pdf

clang ignores template functions for `co_await`?

branch : dev/net

Note

• https://github.com/luncliff/coroutine/blob/dev/net/interface/coroutine/net.h#L108
• https://travis-ci.org/luncliff/coroutine/jobs/528489726#L218

As the error message notes, it seems that co_await operator searches only for member functions.

The following error is from clang 7.1.0 in WSL

clang version 7.1.0-svn353565-1~exp1~20190408084827.60 (branches/release_70)
Target: x86_64-pc-linux-gnu
Thread model: posix
InstalledDir: /usr/bin

The message.

/mnt/d/coroutine/test/c2_socket_echo_tcp.cpp:139:20: error: no member named 'await_ready' in 'io_recv'
    rsz = co_await recv_stream(sd, storage, 0, work);
                   ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/mnt/d/coroutine/test/c2_socket_echo_tcp.cpp:157:20: error: no member named 'await_ready' in 'io_send'
    ssz = co_await send_stream(sd, storage, 0, work);
                   ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/mnt/d/coroutine/test/c2_socket_echo_tcp.cpp:176:20: error: no member named 'await_ready' in 'io_recv'
    rsz = co_await recv_stream(sd, buf = storage, 0, work);
                   ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/mnt/d/coroutine/test/c2_socket_echo_udp.cpp:129:20: error: no member named 'await_ready' in 'io_recv_from'
    rsz = co_await recv_from(sd, remote, storage, work);
                   ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/mnt/d/coroutine/test/c2_socket_echo_tcp.cpp:182:20: error: no member named 'await_ready' in 'io_send'
    ssz = co_await send_stream(sd, buf, 0, work);
                   ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/mnt/d/coroutine/test/c2_socket_echo_udp.cpp:147:20: error: no member named 'await_ready' in 'io_send_to'
    ssz = co_await send_to(sd, remote, storage, work);
                   ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/mnt/d/coroutine/test/c2_socket_echo_udp.cpp:164:24: error: no member named 'await_ready' in 'io_recv_from'
        rsz = co_await recv_from(sd, remote, buf = storage, work);
                       ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/mnt/d/coroutine/test/c2_socket_echo_udp.cpp:168:24: error: no member named 'await_ready' in 'io_send_to'
        ssz = co_await send_to(sd, remote, buf = {storage.data(), rsz}, work);
                       ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
4 errors generated.
make[2]: *** [test/CMakeFiles/coroutine_test.dir/c2_socket_echo_tcp.cpp.o] Error 1
make[2]: *** Waiting for unfinished jobs....
4 errors generated.
make[2]: *** [test/CMakeFiles/coroutine_test.dir/c2_socket_echo_udp.cpp.o] Error 1
make[1]: *** [test/CMakeFiles/coroutine_test.dir/all] Error 2
make: *** [all] Error 2

Survey for common concepts

Note

This is a long term project

Design/Apply some C++ Concepts

References

• http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p1063r0.pdf
• http://open-std.org/JTC1/SC22/WG21/docs/papers/2018/p1288r0.pdf

C++ Concepts

• https://gist.github.com/jeb2239/2c816f0bc75f4a823acb1eb3c55fe286
• https://www.gnu.org/software/gcc/projects/cxx-status.html
• https://en.cppreference.com/w/cpp/language/constraints

Repositories

• https://github.com/iains/gcc-cxx-coroutines
• https://github.com/jamboree/co2
• https://github.com/GorNishanov/coroutines-ts/issues
• https://github.com/GorNishanov/await
• https://github.com/tlanc007/coroutine-ts
• https://github.com/qis/ice-coroutines
• https://github.com/ratiotile/coroutine-demo
• https://github.com/YehezkelShB/CoreCpp2019-Coroutines
• https://github.com/owt5008137/libcopp
• https://github.com/tencent-wechat/libco
• https://github.com/arBmind/2018-cogen-en

Under Review ...

• https://github.com/toby-allsopp/coroutine_func
• https://github.com/jefftrull/coroutine_experiments
• https://github.com/Naios/continuable
• https://www.youtube.com/watch?v=2wz0r2FfJmg

Related Issues

• #33

Working with Concurrency TS

Final decision for the issue

Discarding this suggestion since most of the TS features won't be used in test/example codes.
latch is appropriate, but the others are not that much ...
Also, it will be a heavy burden for their maintenance to enforce standard interfaces. The future code will allow <coroutine/concrt.h> to use some well-known system API functions.

Note

There are already similar features in Concurrency TS.

• from wait_group to latch
• for implementation of suspend_queue: using p0260: concurrent queue

Replacing the current code will be helpful for later maintenance. And it also meets the purpose of the repository: providing an example.

Interface

Candidate for the replacement is sync.h.

// from <coroutine/sync.h>
#include <coroutine/concurrency_adapter.h>

After implementation, the header dependency must remain same.

• concurrency_adapter.h from sync.h
• suspend.h
  • uses concurrency_adapter.h, but not included in the file

Issues

• Possible header collision(redefinition of codes)
• Using another library for the TS
  • Dependency management Issue
  • License

crash of channel in clang release

https://travis-ci.org/luncliff/coroutine/builds/458272794

Note

Debug (with -g) option works as exepected, but Release build yields crash. -O0 option build works well. The crash occurs over -O1 . Seems like optimizer issue.

The testcase is WriteRead, function is write_to. It's weird because its pair ReadWrite test is passed in same build.

Inserting fprintf made the test green. 9b6cc56
Going to check the case with Compiler Explorer

// ensure successful write to channel
template<typename L>
auto write_to(channel<uint64_t, L>& ch, uint64_t value, bool ok = false)
    -> unplug
{
    ok = co_await ch.write(value);

    if (ok == false)
        // inserting fprintf makes the crash disappear.
        // finding the reason for the issue
        fprintf(stdout, "write_to %p %llx \n", &value, value);

    REQUIRE(ok);
}

Releated Feature

• channel

Compiler / System

• AppleClang 9.1.0.9020039 / Darwin-17.4.0
• Clang 6.0.1 / Linux-4.4.0-101-generic (ubuntu)

Test suite should consider current compiler version and SDK

I've learned a lot from current test codes, but most of them are being broken.

In my opinion VS 2019 has worked fine, but currently, the test execution fails and doesn't provide enough information to get insight from the build log.

If possible, each TC should be in a separate file, and there must be the following description in docs.

I have to make a plan for CI builds to achieve the purpose of this repository.

msvc/clang intrinsic

Research about compiler intrinsics and its operation results

Reference

• https://github.com/llvm-mirror/libcxx/blob/bb716549f1a0d445616cf1d2619623a599d12bea/include/experimental/coroutine
• https://clang.llvm.org/docs/LanguageExtensions.html#c-coroutines-support-builtins
• https://llvm.org/docs/Coroutines.html#example

Frame Layout

Mostly memory alignment is multiply of 16.

// from VC++ <experimental/resumable>
template<typename T>
constexpr auto aligned_size_v = ((sizeof(T) + 16 - 1) & ~(16 - 1));

// in short this is `goto` 
using procedure_t = void(__cdecl*)(void*);

Each compiler's memory layout of coroutine frame will be described below.

MSVC

 | Promise | Frame Prefix | Local variables | 
            \
            resumable_handle<void>
address: low-->high

The structure of frame prefix is like this

// - Note
//      MSVC coroutine frame's prefix. See `_Resumable_frame_prefix`
struct msvc_frame_prefix final
{
    procedure_t factivate;
    uint16_t index;
    uint16_t flag;
};
static_assert(sizeof(msvc_frame_prefix) == 16);

Clang

 | Frame Prefix | Promise | ? | Local variables | 
  \
  resumable_handle<void>
address: low-->high

? seems like a guard. When it's corrupted, builtin intrinsics makes a crash.

The structure of frame prefix is like this

// - Note
//      Clang coroutine frame's prefix. See reference docs above
struct clang_frame_prefix final
{
    procedure_t factivate;
    procedure_t fdestroy;
};
static_assert(sizeof(clang_frame_prefix) == 16);

Compiler Intrinsic

intrinsics and their behavior

MSVC

// <experimental/resumable>

extern "C" size_t _coro_resume(void*);
extern "C" void _coro_destroy(void*);
extern "C" size_t _coro_done(void*);

Clang

// <experimental/coroutine>

void __builtin_coro_resume(void *addr);
void __builtin_coro_destroy(void *addr);
bool __builtin_coro_done(void *addr);

Porting Issue

Replacing coroutine frame header

Related Items

• <experimental/coroutine>
• https://github.com/luncliff/coroutine/blob/bugfix/interface/coroutine/frame.h#L147
• 71a3245
• https://ci.appveyor.com/project/luncliff/coroutine/builds/20503754

Compiler / System

• Clang 7.0.0 / Windows-10.0.14393 (AppVeyor: Visual Studio 15 2017)

Note

According to build log and local test, Coroutines that doesn't final_suspend can lead to the access violation. It depends on subtle timing. The crash point is like followings. <coroutine/frame.h>

inline size_t _coro_resume(void* addr)
{
    auto* c = reinterpret_cast<clang_frame_prefix*>(addr);
    __builtin_coro_resume(c);
    // ...
    return _coro_done(addr); 
}

inline size_t _coro_done(void* addr)
{
    auto* m = reinterpret_cast<msvc_frame_prefix*>(addr);
    auto* c = reinterpret_cast<clang_frame_prefix*>(addr);

    if (__builtin_coro_done(c)) // <------------ !!! The Crash Point !!!
    {
        std::swap(c->factivate, c->fdestroy);
    }
    return m->index;
}

So it is clear that the access violation is from __builtin_coro_done for destroyed coroutine frame.

Since the purpose of those intrinsic implementation is to adapt diffence between libc++ and VC++ headers, the real problem is difference between header files.

Possible solution for this issue is replacing
<experimental/coroutine> to another implementation, but it can be
another kind of burden for the library

Coroutine build failed with error C7651

I am a member of Microsoft VCPKG team. In an internal version of Visual Studio, coroutine build failed with error C7651:

buildtrees\coroutine\src\1.5.0-36192178c9.clean\modules\portable\frame.cpp(136): error C7651: __builtin_coro_resume cannot be used with /await. Use '/std:c++latest' or later for standard coroutine support
buildtrees\coroutine\src\1.5.0-36192178c9.clean\modules\portable\frame.cpp(144): error C7651: __builtin_coro_destroy cannot be used with /await. Use '/std:c++latest' or later for standard coroutine support

This issue due to an internal change in compiler. For fixing this issue, we need to introduce a set of wrapper functions in frame.cpp so that the calls to __builtin_coro_* only appear in templates with a value-dependent condition. Then in the portable_coro_(done|resume|destroy) functions replace the call to __builtin_coro_* with a call to the appropriate wrapper with a template argument <true>.
I have added a patch to solve this problem temporarily on VCPKG, the related PR microsoft/vcpkg#12456. I submit this issue and want to fix this error on upstream.

Thanks a lot.

build support: clang-9

Summary

LLVM package updated: 9.0.0

https://dev.azure.com/luncliff/personal/_build/results?buildId=815

Note

Chocolatey package info

Running Chocolatey Version: 0.10.15
Chocolatey v0.10.15
Installing the following packages:
llvm
By installing you accept licenses for the packages.

llvm v9.0.0 [Approved]
llvm package files install completed. Performing other installation steps.
WARNING: Url has SSL/TLS available, switching to HTTPS for download
Downloading llvm 64 bit
  from 'https://releases.llvm.org/9.0.0/LLVM-9.0.0-win64.exe'

Download of LLVM-9.0.0-win64.exe (150.6 MB) completed.

Seems like there is an issue for channel types.

[17/114] Building CXX object test\CMakeFiles\test_channel_read_fail_after_close.dir\channel_read_fail_after_close.cpp.obj
FAILED: test/CMakeFiles/test_channel_read_fail_after_close.dir/channel_read_fail_after_close.cpp.obj 
C:\PROGRA~1\LLVM\bin\clang-cl.exe  /nologo -TP -DCMAKE_TEST -DFORCE_STATIC_LINK -DNOMINMAX -DUSE_PORTABLE_COROUTINE_HANDLE -DWIN32_LEAN_AND_MEAN -D_CRT_SECURE_NO_WARNINGS -D_RESUMABLE_FUNCTIONS_SUPPORTED -Iexternal\guideline\include -Imodules\concrt -Iinterface -Imodules\thread -Itest -Imodules\event /DWIN32 /D_WINDOWS /W3 /GR /EHsc -Xclang -fcoroutines-ts /MDd /Zi /Ob0 /Od /RTC1   /std:c++latest -fms-compatibility -Xclang -fcoroutines-ts -std:c++17 /showIncludes /Fotest\CMakeFiles\test_channel_read_fail_after_close.dir\channel_read_fail_after_close.cpp.obj /Fdtest\CMakeFiles\test_channel_read_fail_after_close.dir\ -c test\channel_read_fail_after_close.cpp
test\channel_read_fail_after_close.cpp(20,5): warning: control reaches end of non-void lambda [-Wreturn-type]
    };
    ^
test\channel_read_fail_after_close.cpp(24,23): note: in instantiation of function template specialization 'coro_channel_read_return_false_after_close_test()::(anonymous class)::operator()<coro::channel<int, coro::bypass_lock>, int>' requested here
    auto h = coro_read(*ch, item);
                      ^
In file included from test\channel_read_fail_after_close.cpp:5:
In file included from interface\coroutine/channel.hpp:15:
interface\coroutine/frame.h(386,30): warning: unused function 'noop_coroutine' [-Wunused-function]
static noop_coroutine_handle noop_coroutine() noexcept {
                             ^
Stack dump:
0.	Program arguments: C:\PROGRA~1\LLVM\bin\clang-cl.exe -cc1 -triple x86_64-pc-windows-msvc19.16.27032 -emit-obj -mrelax-all -mincremental-linker-compatible -disable-free -disable-llvm-verifier -discard-value-names -main-file-name channel_read_fail_after_close.cpp -mrelocation-model pic -pic-level 2 -mthread-model posix -relaxed-aliasing -fmath-errno -masm-verbose -mconstructor-aliases -munwind-tables -target-cpu x86-64 -mllvm -x86-asm-syntax=intel -D_DEBUG -D_MT -D_DLL --dependent-lib=msvcrtd --dependent-lib=oldnames --show-includes -stack-protector 2 -fcxx-exceptions -fexceptions -fexternc-nounwind -fms-volatile -fdiagnostics-format msvc -gcodeview -debug-info-kind=limited -momit-leaf-frame-pointer -coverage-notes-file D:\a\1\s\channel_read_fail_after_close.gcno -resource-dir C:\PROGRA~1\LLVM\lib\clang\9.0.0 -D CMAKE_TEST -D FORCE_STATIC_LINK -D NOMINMAX -D USE_PORTABLE_COROUTINE_HANDLE -D WIN32_LEAN_AND_MEAN -D _CRT_SECURE_NO_WARNINGS -D _RESUMABLE_FUNCTIONS_SUPPORTED -I external\guideline\include -I modules\concrt -I interface -I modules\thread -I test -I modules\event -D WIN32 -D _WINDOWS -internal-isystem C:\PROGRA~1\LLVM\lib\clang\9.0.0\include -internal-isystem C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\VC\Tools\MSVC\14.16.27023\ATLMFC\include -internal-isystem C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\VC\Tools\MSVC\14.16.27023\include -internal-isystem C:\Program Files (x86)\Windows Kits\NETFXSDK\4.6.1\include\um -internal-isystem C:\Program Files (x86)\Windows Kits\10\include\10.0.17763.0\ucrt -internal-isystem C:\Program Files (x86)\Windows Kits\10\include\10.0.17763.0\shared -internal-isystem C:\Program Files (x86)\Windows Kits\10\include\10.0.17763.0\um -internal-isystem C:\Program Files (x86)\Windows Kits\10\include\10.0.17763.0\winrt -internal-isystem C:\Program Files (x86)\Windows Kits\10\include\10.0.17763.0\cppwinrt -O0 -Wall -fdeprecated-macro -fdebug-compilation-dir D:\a\1\s -ferror-limit 19 -fmessage-length 0 -fno-use-cxa-atexit -fms-extensions -fms-compatibility -fms-compatibility-version=19.16.27032 -std=c++17 -fdelayed-template-parsing -fno-inline -fobjc-runtime=gcc -fdiagnostics-show-option -fcoroutines-ts -fcoroutines-ts -faddrsig -o test\CMakeFiles\test_channel_read_fail_after_close.dir\channel_read_fail_after_close.cpp.obj -x c++ test\channel_read_fail_after_close.cpp 
1.	<eof> parser at end of file
2.	Per-file LLVM IR generation
3.	test\channel_read_fail_after_close.cpp:18:22: Generating code for declaration 'coro_channel_read_return_false_after_close_test()::(anonymous class)::operator()'
 #0 0x00007ff69f79aa0c (C:\PROGRA~1\LLVM\bin\clang-cl.exe+0x301aa0c)
 #1 0x00007ff69dfc3caf (C:\PROGRA~1\LLVM\bin\clang-cl.exe+0x1843caf)
 #2 0x00007ff69e243901 (C:\PROGRA~1\LLVM\bin\clang-cl.exe+0x1ac3901)
 #3 0x00007ff69e283174 (C:\PROGRA~1\LLVM\bin\clang-cl.exe+0x1b03174)
 #4 0x00007ff69e1f0d48 (C:\PROGRA~1\LLVM\bin\clang-cl.exe+0x1a70d48)
 #5 0x00007ff69e115cc8 (C:\PROGRA~1\LLVM\bin\clang-cl.exe+0x1995cc8)
 #6 0x00007ff69e116599 (C:\PROGRA~1\LLVM\bin\clang-cl.exe+0x1996599)
 #7 0x00007ff69df9cb1d (C:\PROGRA~1\LLVM\bin\clang-cl.exe+0x181cb1d)
 #8 0x00007ff69df961e7 (C:\PROGRA~1\LLVM\bin\clang-cl.exe+0x18161e7)
 #9 0x00007ff69df8bb45 (C:\PROGRA~1\LLVM\bin\clang-cl.exe+0x180bb45)
#10 0x00007ff69df8abe1 (C:\PROGRA~1\LLVM\bin\clang-cl.exe+0x180abe1)
#11 0x00007ff69fb4bd75 (C:\PROGRA~1\LLVM\bin\clang-cl.exe+0x33cbd75)
#12 0x00007ff69fb498cb (C:\PROGRA~1\LLVM\bin\clang-cl.exe+0x33c98cb)
#13 0x00007ff69eedb4c3 (C:\PROGRA~1\LLVM\bin\clang-cl.exe+0x275b4c3)
#14 0x00007ff69e433492 (C:\PROGRA~1\LLVM\bin\clang-cl.exe+0x1cb3492)
#15 0x00007ff69e3f71cf (C:\PROGRA~1\LLVM\bin\clang-cl.exe+0x1c771cf)
#16 0x00007ff69e489c87 (C:\PROGRA~1\LLVM\bin\clang-cl.exe+0x1d09c87)
#17 0x00007ff69c786e87 (C:\PROGRA~1\LLVM\bin\clang-cl.exe+0x6e87)
#18 0x00007ff69c784564 (C:\PROGRA~1\LLVM\bin\clang-cl.exe+0x4564)
#19 0x00007ff69fb5da20 (C:\PROGRA~1\LLVM\bin\clang-cl.exe+0x33dda20)
#20 0x00007ffac0f184d4 (C:\windows\System32\KERNEL32.DLL+0x84d4)
#21 0x00007ffac132e851 (C:\windows\SYSTEM32\ntdll.dll+0x6e851)
clang-cl: error: clang frontend command failed due to signal (use -v to see invocation)
clang version 9.0.0 (tags/RELEASE_900/final)
Target: x86_64-pc-windows-msvc
Thread model: posix
InstalledDir: C:\PROGRA~1\LLVM\bin
clang-cl: note: diagnostic msg: PLEASE submit a bug report to https://bugs.llvm.org/ and include the crash backtrace, preprocessed source, and associated run script.
clang-cl: note: diagnostic msg: 
********************

PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT:
Preprocessed source(s) and associated run script(s) are located at:
clang-cl: note: diagnostic msg: C:\Users\VSSADM~1\AppData\Local\Temp\channel_read_fail_after_close-367a13.sh
clang-cl: note: diagnostic msg: 

********************

Review: Open Standard Docs

Glad for the C++20 report!

References

Shortcut to find related documents

• C++ Draft Repo
• ISO C++ Blog

Note

Some users might need a summary / commentary for the open c++ documents.

To Do

• N4800
• n4736
  • n4723
• p0664r0
• p0664r4
• 2018-06-24: p0664r5
• 2018-10-04: p0664r6
• 2019-01-16: p0664r7

P0664

R0

Core Issues

• await-expression has the same type and value category as the await-resume expression
• promise_type's unhandled_exception leads to std::terminate by default.
• Possible undefined behavior - none
• co_return <expr> statement with void

Core Comments (C++17)

• range-based for statement
• hash support for coroutine_handle
• Coroutine handles have essentially raw pointer semantics.(low level type)
• constexpr from_address

LWG Issues

• a concurrent resumption of a coroutine by multiple threads may result in a data race

Evolution

• TS disallows stackful coroutines
• avoid both return_void and return_value

R4

Evolution/Core Issues

• 11.4.4 [dcl.fct.def.coroutine]
  • initial_suspend and execution agent
• http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0664r4.html#25

LWG Issues

• const on coroutine_handle::resume() was removed:

Going to review with N4736

R5

CWG Issues

• exception thrown after the initial suspend point and before the flow of execution reaches F also results in entering the handler of the try-block >> any link?
• an exception to escape p.unhandled_exception() and, in that case, consider the coroutine to be at the final suspend point
• One of the implementation strategies for coroutines is to chop original function into as many functions (parts) as there are suspend points.

Rapperswil 2018 issues

• const on coroutine_handle::resume() was removed
  • it does make writing lambdas capturing coroutine_handle more verbose.

R6

CWG Issues

• 33: ... When a coroutine is invoked, a copy is created for each coroutine parameter ... use of a parameter in the function-body of the coroutine and in the call to the coroutine promise constructor is replaced by a reference to its copy ... The lifetime of parameter copies ends immediately after the lifetime of the coroutine promise object ends.

R7

LWG Issues

• A concurrent resumption of the coroutine via resume, operator(), or destroy may result in a data race

EWG Issues

• Parameter copy wording
• Removing for co_await statement

CWG Issues

in progress ...

Package support

Vcpkg

• requires: ms-gsl package
• architecture: x64 only
• compiler: msvc, clang, AppleClang

search issue with [coroutine]

NuGet

not in plan

Conan

not in plan

USE_PORTABLE_COROUTINE_HANDLE has no effect

In the ReadMe (at main branch) it said "It can be activated with macro USE_PORTABLE_COROUTINE_HANDLE".

However, I cannot find any usage of "USE_PORTABLE_COROUTINE_HANDLE" in this repo.

After reading the code at coroutine/frame.h, I think there is no way to use the coroutine_handle in the STL in linux with g++. That means I can only use your implementation in coroutine/frame.h

Webassembly

How hard would it be to make the co_await work on clang 8 and webassembly?

Builtins are missing on macOS 13.5/XCode 14.3.1

[5/11] /Library/Developer/CommandLineTools/usr/bin/c++  -I/Users/vagrant/Data/buildtrees/coroutine/src/1.5.0-46f8d90e7d.clean/modules/system -I/Users/vagrant/Data/buildtrees/coroutine/src/1.5.0-46f8d90e7d.clean/interface -I/Users/vagrant/Data/installed/x64-osx/include -fPIC -g -std=gnu++17 -arch x86_64 -isysroot /Library/Developer/CommandLineTools/SDKs/MacOSX13.3.sdk -std=c++2a -stdlib=libc++ -fcoroutines-ts -MD -MT modules/system/CMakeFiles/coroutine_system.dir/darwin.cpp.o -MF modules/system/CMakeFiles/coroutine_system.dir/darwin.cpp.o.d -o modules/system/CMakeFiles/coroutine_system.dir/darwin.cpp.o -c /Users/vagrant/Data/buildtrees/coroutine/src/1.5.0-46f8d90e7d.clean/modules/system/darwin.cpp
FAILED: modules/system/CMakeFiles/coroutine_system.dir/darwin.cpp.o 
/Library/Developer/CommandLineTools/usr/bin/c++  -I/Users/vagrant/Data/buildtrees/coroutine/src/1.5.0-46f8d90e7d.clean/modules/system -I/Users/vagrant/Data/buildtrees/coroutine/src/1.5.0-46f8d90e7d.clean/interface -I/Users/vagrant/Data/installed/x64-osx/include -fPIC -g -std=gnu++17 -arch x86_64 -isysroot /Library/Developer/CommandLineTools/SDKs/MacOSX13.3.sdk -std=c++2a -stdlib=libc++ -fcoroutines-ts -MD -MT modules/system/CMakeFiles/coroutine_system.dir/darwin.cpp.o -MF modules/system/CMakeFiles/coroutine_system.dir/darwin.cpp.o.d -o modules/system/CMakeFiles/coroutine_system.dir/darwin.cpp.o -c /Users/vagrant/Data/buildtrees/coroutine/src/1.5.0-46f8d90e7d.clean/modules/system/darwin.cpp
/Users/vagrant/Data/buildtrees/coroutine/src/1.5.0-46f8d90e7d.clean/modules/system/darwin.cpp:33:1: error: static_assert failed
static_assert(__has_builtin(__builtin_coro_param));
^                                               ~
1 error generated.

Looks like this builtin is gone?

Coroutine Frame support for the GCC-10(coroutines branch)

Note

Until we can get the stable build from major package managers, this repo will use Docker Container. https://travis-ci.org/luncliff/coroutine/builds/561619498

References

Inherit references from #33

• https://github.com/iains/gcc-cxx-coroutines
  • coroutines test codes
  • concepts test codes
• https://gcc.gnu.org/wiki/cxx-coroutines
• svn://gcc.gnu.org/svn/gcc/branches/c++-coroutines
• https://gcc.gnu.org/wiki/cauldron2019talks?action=AttachFile&do=view&target=Coroutine-Cauldron-2019.pdf&fbclid=IwAR1b6xH5cNXokALQZHc45IPInHlta9X9NDDIHqO4TZdiHijTyjeXQISaer0

To Do

• Frame layout
• Compiler built-in functions
  • compare with those of Clang
• Guide document for using the luncliff/gcc Docker image
  • scp to get the binary

Related Issues

Previous Works

• #1 #6 msvc/clang intrinsic

History

• #33 gcc for coroutines

Thread Message Queue

Note

This is a base feature for switch_to.

Current version is lock-based circular queue. modules/thread/queue.cpp file of commit 3c8e64c includes the implementation

Possible enhancement

• Filtering purpose
• Priority
• Indicating drop of messages(leakage)

Priority and indication will be out of concern unless they are required. In the case, library will add appropriate dependency to fulfill the requirement.

Related Issue

• #10 #11

Preparing GCC for Coroutine project

Note

Going to start with the branch dev/gcc.
This issue will deal with acquiring GCC binaries. Next issue of this will handle for the project configuration.

Going to start with the branch of GCC which supports -fcoroutines flag. The plan is using Docker build to make ease of to reuse/share binaries.

References

• https://github.com/namhyung/uftrace/wiki/uftrace-for-gcc-compiler?fbclid=IwAR1J0mcTRkRbAhg9LC9xUAH1_cE7dLSSGDEXlDeuMVVBtBJsTaPtokHi29k

GCC

• https://gcc.gnu.org/wiki/cxx-coroutines
• svn://gcc.gnu.org/svn/gcc/branches/c++-coroutines
• https://gcc.gnu.org/install/index.html
• http://www.linuxfromscratch.org/lfs/view/stable/chapter05/gcc-pass1.html
• https://solarianprogrammer.com/2016/10/07/building-gcc-ubuntu-linux/

Repo

• https://github.com/iains/gcc-cxx-coroutines