Skip to content
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

give coroutines direct access to their promise #28

Open
imoldfella opened this issue Dec 13, 2017 · 0 comments
Open

give coroutines direct access to their promise #28

imoldfella opened this issue Dec 13, 2017 · 0 comments

Comments

@imoldfella
Copy link

imoldfella commented Dec 13, 2017

TS generators can only access the promise indirectly through co_yield. Macro based coroutines can access the promise area directly, and can use it to pass information in to coroutines as well as get information out. For example a coroutine that begins on one thread could be resumed on another thread; passing a pointer to thread specific information in the promise structure could be faster and more disciplined than using a thread_local variable for the same purpose.

One possible implementation would be to have a keyword co_promise that returns a pointer to the promise, analogous to the "this" pointer for accessing member variables.

Another useful way to pass information into the coroutine would be to allow the promise to set the type signature of the resume function. For example if we wanted to send the current thread data to a coroutine resume in a register we could have
struct promise_type
{
using resume_type = void(*)(void*, some_thread_specific_data);
...
If you think any of these proposals have any chance of moving forward I would be willing to take a crack at them in Clang. I think the new coroutines are best thing to happen to C++ since lambdas, but I really want them to be better in every way than the macro-style coroutines people use today.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant