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. > -- 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_rtH30_yvns0RENoWHQoaM6XN96b89uBHqTTL%3DKZ%3DituDrA%40mail.gmail.com.
