A lot of the CQ-based API was designed around the idea that the application could tune performance by deciding which activity was going to occur on which CQ and then deciding which thread(s) were going to poll each CQ. So in the case you're asking about, the API allows using one CQ to get the new call request on and then another CQ to actually perform operations on that individual call (which effectively controls which fds are polled on which threads).
In practice, what we've found is that the CQ-based API is way too complicated, and basically no one actually needs the level of performance control that it was designed to provide. So we're currently working on changing to a polling model where the event engine provides all polling threads and the application API is a simpler callback-based model. We will continue to support the CQ-based API, but it will still use the new polling model under the hood. Once that happens, the CQ-based API will still continue to work the same way it does today, but moving some of the work to a different CQ may no longer actually have the performance benefit that it might today, so there's probably no reason to ever do that. On Sat, Apr 17, 2021 at 12:49 PM Kirill Katsnelson <[email protected]> wrote: > For an async C++ server, the method declaration generated by the C++ > protoc plugin takes two completion queues: new_call_cq and > notification_cq. The former is declared as a more derived > ServerCompletionQueue*, the latter is "just" a CompletionQueue*. I'm in > the habit of using one CQ for both, which I likely picked up from the async > hello world example. This works, so I do not fix it. > > But for the life of me, I could not find any information why the async > interface accepts two CQs, and what are the use cases which benefit from > two separate CQ w.r.t. a call. Any info out there? > > -kkm > > -- > 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/d5754f98-6711-45ff-9000-b178e457d9can%40googlegroups.com > <https://groups.google.com/d/msgid/grpc-io/d5754f98-6711-45ff-9000-b178e457d9can%40googlegroups.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/CAJgPXp48wBn-4U1x0r6%2BDhMk4JJts0Y7iAJadN3WAoraHJpETw%40mail.gmail.com.
