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

Question

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_cq 和notification_cq 有什么区别？使用差异完成队列的潜在用途/好处是什么？

Answer 1

当被问到同样的问题时，这是来自 grpc 的 google-groups 论坛的引述。 https://groups.google.com/forum/#!topic/grpc-io/V4NAQ77PMEo

Notification_cq 取回表示呼叫已开始的标记。该调用上的所有后续操作（读取、写入等）都报告回 call_cq。对于大多数异步服务器，我的建议是使用相同的 cq。您可能不会去的地方：

1. 我们的同步 API 会在后台为每个调用创建一个 cq...因此它会为 notification_cq 发布一个通用事件 >queue，它是 call_cq 的特定队列。
2. 如果您希望能够控制何时接听来电与何时不接听（通过在 notification_cq 上暂停轮询）
3. 我相信人们可以为他人着想。

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