Support Croutine based async grpc server cpp++

[Lei Wang]

It is much easier for us to implement coroutine in python, java, and machines with VM so that we can monitor the memory address where we are executing.

in grpc c++, we recommend to use glib ucontext, which is widely employed by our c++ developers and we could use it stop, consume threads for c++. By deveoping Future so and wrapped async io event, we can jump back to memory address where we wait for a task done.

I would not recommend implementing async server completion queue callback because it will be eventually replaced by a solution first released as the coutine version async grpc.

[Lei Wang]

Also see proposal https://github.com/grpc/grpc/issues/18204

[Vijay Pai]

So several months ago, we started considering ongoing directions for evolving the C++ API. Certainly, a major concern was that it is difficult to use the async CQ-based API. If you've been following the repo recently, though, you see that we're headed in a direction of a callback-based API. 

As much as some of us (including me) wanted to base a system on futures, there hasn't yet been an acceptance of the C++ concurrency TS into an ISO standard for C++, and the C++11 futures API is just too limited to be practical. We also considered using futures from an external library but were concerned about not only introducing an extra dependence but also the likelihood that that would lead to a bifurcation in development practices when a reasonable future implementation reaches the C++ standard.

So, among the options that we considered, the callback-based API seemed most practical, usable, and ready for use. That said, it's still experimental for the time being, with a plan of making it generally available in the next few months. In the meanwhile, please feel free to look over the API and tests.

https://grpc.io/grpc/cpp/namespacegrpc_1_1experimental.html (which also includes other features)

https://github.com/grpc/grpc/blob/master/test/cpp/end2end/client_callback_end2end_test.cc (which tests the client-side of the callback API)

https://github.com/grpc/grpc/blob/master/test/cpp/end2end/test_service_impl.cc (which tests the server-side of the sync and callback APIs)

- Vijay

[sumuk...@gmail.com]

Thanks Vijay. This makes sense.

I posted a related question today( Callback based Async programming model in C++) and found this thread on searching here.

Is there a link to the design notes on how this feature is being built? Are the callbacks just a convenience built on top of the completion queue mechanism, which still relies on the epoll mechanism underneath?