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 On Thursday, February 28, 2019 at 2:01:06 AM UTC-8, Lei Wang wrote: > > Also see proposal https://github.com/grpc/grpc/issues/18204 > > On Thursday, February 28, 2019 at 3:32:27 PM UTC+8, Lei Wang wrote: >> >> 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. >> > -- You received this message because you are subscribed to the Google Groups "grpc.io" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/grpc-io. To view this discussion on the web visit https://groups.google.com/d/msgid/grpc-io/5db40fbe-bfac-467d-93ce-2e588ef38d6c%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
