We haven't yet published gRFCs for either the EventManager API or for the C++ reactor-based API, but look for those to be available within the next couple of months.
For the C++ reactor-based API, we do have some tests you can look at as examples. For server-side, see here <https://github.com/grpc/grpc/blob/85d25bd9902a68e4c43ee0afd392358133f580e4/test/cpp/end2end/test_service_impl.h#L118>, and for client-side, see here <https://github.com/grpc/grpc/blob/master/test/cpp/end2end/client_callback_end2end_test.cc> . I hope this info is helpful! On Wed, Mar 18, 2020 at 1:11 PM Satyam Shekhar <[email protected]> wrote: > Thanks for the update. This is really helpful. > > Can you provide some samples of the EventManager API and reactor API? That > will enable us to design our system to be amenable to future changes. > > Regards, > Satyam > > On Wed, Mar 18, 2020 at 11:06 AM Mark D. Roth <[email protected]> wrote: > >> We don't intend to support applications injecting their own events into a >> gRPC completion queue. In fact, the only reason that mechanism exists >> under the hood is that it's part of our effort to transition away from the >> completion queue-based API. Read on for details. >> >> We don't currently have a mechanism that allows integrating gRPC into an >> external event loop, although we are in the process of making some changes >> that will allow that. Basically, we are currently working on introducing >> an EventManager API and changing C-core to use that API for polling. We >> will provide an EventManager implementation based on libuv, but >> applications that wish to integrate gRPC with an external event loop will >> be able to supply their own EventManager implementations that wrap their >> external event loop, in which case gRPC can be driven by that external >> event loop. >> >> Once we move to EventManager-based polling, we will be able to make the >> new reactor-based C++ async API available in OSS (we're already using it >> internally), and we will encourage people to use that API instead of the >> current completion queue-based API. The reactor API is much easier to use >> for most applications. >> >> The current ETA for making the EventManager API available and finishing >> the libuv-based EventManager implementation is the end of April, so stay >> tuned for more information. >> >> I hope this information is helpful! >> >> On Tue, Mar 17, 2020 at 4:40 PM Satyam Shekhar <[email protected]> >> wrote: >> >>> Hello, >>> >>> I am trying to build a high-performance server with GRPC. As recommended >>> in performance notes for cpp, I wish to create 1 completion-queue per CPU >>> and tie 1 completion-queue per thread. I'd prefer to avoid any other thread >>> in my system. All threads would continuously poll from their respective >>> completion-queue and process read events. >>> >>> The server also has interactions with other IO systems - say Kafka. For >>> this model to work efficiently, the server should be able to schedule other >>> events (say Kafka write finished) on completion-queue to avoid polling >>> multiple IO services. >>> >>> Grpcpp CompletionQueue interface does not support scheduling events. >>> Core surface API has that interface but that is not publicly visible via >>> Bazel. >>> >>> I am looking for guidance on the following questions - >>> >>> 1. Is this approach recommended? >>> 2. If yes, how can I schedule events on CompletionQueue? >>> 3. What other alternatives should we consider? >>> >>> Regards, >>> Satyam >>> >>> -- >>> 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 view this discussion on the web visit >>> https://groups.google.com/d/msgid/grpc-io/CAAy_rtHxP7YmEMJD5wTDKG%3DDsXW41qWZzOzHczcPgoZDo4H0bg%40mail.gmail.com >>> <https://groups.google.com/d/msgid/grpc-io/CAAy_rtHxP7YmEMJD5wTDKG%3DDsXW41qWZzOzHczcPgoZDo4H0bg%40mail.gmail.com?utm_medium=email&utm_source=footer> >>> . >>> >> >> >> -- >> Mark D. Roth <[email protected]> >> Software Engineer >> Google, Inc. >> > -- Mark D. Roth <[email protected]> Software Engineer Google, Inc. -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/grpc-io/CAJgPXp4eprjCQtasyZO-vFJi5NtGd4nAmuw45kjP%2BnUi0GtV7w%40mail.gmail.com.
