Any plan to add c++20 coroutine support？ about flare HOT 2 CLOSED

Not planned yet.

The main reason is that the compiler we're using internally (GCC 8) does not support C++20 coroutine. That means we won't be able to test coroutine support throughly in production environment (were it implemented).

I have't looked deeply enough into C++20 coroutine. The following is based on my preliminary understanding.

Were it to be implemented, I'd expect operator co_await overload for Future<T> to be provided. This way the following should be possible:

Future<...> AsyncDoSomething() {
  co_await some_client.AsyncDoSomeOtherThing();
}

However, I don't see much point in doing this, when compared with:

... DoSomething() {
  some_cient.DoSomeOtherThing();
}

The reason is that, to permit concurrent packet deserialization, the framework nonetheless needs to use a dedicated fiber for each request.

Therefore we always have one dedicated stack for each request, regardless whether we're using a stackless coroutine to handle it, or handling it directly in fiber. This ruins the main point of using C++20 coroutine (allocating state on heap and avoid using a stack).

Besides, by using a dedicated stack (which is allocated quickly enough in fast path, using our object pool), we can (hopefully) allocate most states (ignoring indirect allocations done by containers) simply by adjusting the stack pointer, without incurring calls to memory allocator. This is generally a performance gain. To the contrary, C++20 coroutine would require the compiler to do one heap allocation for each call to coroutine (unless the compiler is able to optimize that away, in certain cases).

That said, I do see a point in supporting waiting for coroutine result in fiber though, such as:

flare::fiber::WaitOnAwaitable(some_cpp20_async_read_function());

This would allow us to interoperate with libraries using C++20 coroutine, once they're widely spreaded.

I'd expect this to be done once we upgraded our compiler to a more recent one. This should be trivially implementable using an approach similar to cppcoro::sync_wait (using fiber-friendly synchronization primitives).

(Here I'm assuming the coroutine does "return" only once. For generator-alike coroutines, as far as I understand
it, it's need no support from the underlying framework.)

from flare.

Thanks for your detailed reply. I will read the code to get a deeper understanding.

from flare.