Abstract coroutine implementation

[s-panferov]

Hello @Xudong-Huang. Thanks for the amazing library. I am personally do not have knowledge to write a good coroutine implementation, so I patiently sit and wait while someone write one to use it in my projects. And I've already seen several attempts to do so with different api and different implementation details.

To properly use such coroutine library it has to have an ecosystem around with several libraries with file/networking api and other utility stuff. Is it possible to write such a client library in the abstract way, which will work with different coroutine implementations?

As I understand, if go function will be a macro (it already is a macro in your library), and yield function will be a macro, then a client library can just call it without having to know which specific library will provide the implementation. I expect that this specification can be made in an application, which uses the library.

So my primary question: Can we write a client library that uses stackful coroutines without having to know which exact implementation it uses?

[Xudong-Huang]

thanks @s-panferov. Yes, I also notice those attempts that trying to make coroutine based systems. Actually those libraries such as mioco and coio-rs are started very earlier than I begin to develop May. But I have very little experience in using those libraries.

Coroutines are just user space threads, so the most sensible abstraction over coroutines is supply a thread like API set for it, and user can have the freedom to switch to any kind of implementations. e.g.
std::thread::* vs may::coroutine::* and other libraries could be something like xxx::coroutine::*

not only the thread model should be compatible, but all kinds of blocked version APIs such as IO and Sync Primitives should all be compatible with libstd

Actually go! macro is just a thin wrapper around the unsafe spawn API, which would save users some types. And in coroutine you should never call yield, this is a generator concept. in coroutines, users only have normal system APIs.

Yes, it's possible to have a "front" wrapper library, but it's not an easy thing that all coroutine libraries that support the same compatible APIs.