gRPC中的call_cq和notification_cq有什么区别?

时间:2018-07-20 04:36:46

标签: grpc

https://github.com/grpc/grpc/blob/master/examples/cpp/helloworld/greeter_async_server.cc#L91

        service_->RequestSayHello(&ctx_, &request_, &responder_, cq_, cq_,
                                  this);

cq_的两次出现对我来说似乎很奇怪,因此我深入研究了导致我进入的源代码

https://github.com/grpc/grpc/blob/master/include/grpcpp/impl/codegen/service_type.h#L92

  void RequestAsyncUnary(int index, ServerContext* context, Message* request,
                         internal::ServerAsyncStreamingInterface* stream,
                         CompletionQueue* call_cq,
                         ServerCompletionQueue* notification_cq, void* tag) {
    server_->RequestAsyncCall(methods_[index].get(), context, stream, call_cq,
                              notification_cq, tag, request);
  }

那么call_cqnotification_cq有什么区别?使用差异完成队列的潜在用途/好处是什么?

1 个答案:

答案 0 :(得分:0)

当有人问同样的问题时,这是google-groups论坛上grpc的报价。 https://groups.google.com/forum/#!topic/grpc-io/V4NAQ77PMEo

  

Notification_cq返回该标记,指示已开始通话。该呼叫上的所有后续操作(读取,写入等)都会报告给call_cq。对于大多数异步服务器,我的建议是使用相同的CQ。您可能不喜欢的地方:

     
      
  1. 我们的同步API在幕后为每个调用创建了一个cq ...因此,它发布了一个常规事件> notification_cq的队列,它的特定队列为call_cq。
  2.   
  3. 如果您希望能够控制何时接听来电或不接听来电(通过在Notification_cq上暂停轮询)
  4.   
  5. 我确定人们会想到其他人。
  6.   

这允许对哪些线程处理哪些类型的事件(基于它们正在轮询的队列)进行细粒度的控制。就像您可能有一个主线程轮询notification_cq,而工作线程都轮询自己的call_cqs或类似的东西。