You can use as many or as few CQs as you choose. Some of our examples use 1 CQ for the whole application, some use multiple CQs per server. Either way, the CQ is thread-safe. The tradeoff is a basic one of contention (more CQs means less lock contention in the CQ) vs work stranding (1 CQ means that any thread can pick up any piece of work, so less chance of having available threads while the system as a whole is idle). Generally speaking, we recommend 1 CQ unless there is a strong reason to use multiple.
On Saturday, September 19, 2020 at 6:22:36 PM UTC-7 river wrote: > using grpc c++‘s async server api, should i add one cq per rpc method or > just one cq for all service? > > I am taking over a grpc c++ service in my job. it use 10 completionqueue > for a async service method , and yet another 20 completionqueue for another > stream service method. The handling of the completionqueue is quite similar > to the helloworld async service example, except that it use one thread > worker per completionqueue. > > Such a design is not very convenient for adding more service method. And I > am thinking that refactoring it to using just one completionqueue, and > dispatching the tags in the completionqueue to my own domain transactions > handling thread pool. Is it a right disign pattern or is there any better? > -- 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/e45877f1-e38e-4d8f-b4c7-4fee00310cedn%40googlegroups.com.
