GRPC-C++源码分析(九)--Start续（grpc c++教程）

2 SyncRequestThreadManager->Start

解释第二部分代码

  //第二部分
  for (auto it = sync_req_mgrs_.begin(); it != sync_req_mgrs_.end(); it++) {
    (*it)->Start();
  }

看下(*it)->Start()的实现

  void Start() {
    if (!sync_requests_.empty()) {
      for (auto m = sync_requests_.begin(); m != sync_requests_.end(); m++) {
        (*m)->SetupRequest();
        (*m)->Request(server_->c_server(), server_cq_->cq());
      }

      Initialize();  // ThreadManager's Initialize()
    }
  }

先忽略sync_requests_部分，后边再说，重点看Initialize()里的实现。这里分两部分说，第一部分说整个框架逻辑，第二部分分析具体函数调用逻辑。

2.1 Start框架逻辑

抽象的看epoll模型的核心运转模式。直接看图14-1

• 注意下蓝色框内容，grpc里的读写事件处理是在一个“统一的循环里”，而这个统一的循环由grpc_core::ExecCtx::Get()->Flush()来控制
• 图14-2演示了Flush是如何调度任务的

• 1、2箭头过后，已经把readable或者writable的任务放入了closure_list中
• 3箭头开始for循环执行Flush操作，Flush会执行closure_list的任务，当closure_list为空后，会执行combiner_data中的任务
• 第一种场景：执行closure_list中的job1，又生成了新的job1-1放入了closure_list中，见路径：4-4.1-4.2-4.3
• 第二种场景：执行closure_list中的job1，又生成了新的job1-1放入了combiner_data中，见路径：4-4.1-4.4-4.5
• 第三中场景：执行combiner_data中的job2，又生成了新的job2-1放入了combiner_data中，见路径：5-5.1-5.2-5.3
• 第四种场景：执行combiner_data中的job2，又生成了新的job2-1放入了closure_list中，见路径：5-5.1-5.4-5.5

2.2 具体函数逻辑

2.2.1 PollForWork

先看PollForWork部分逻辑，PollForWork在for循环中epoll_wait等待client链接

下面先介绍accept描述符的建立和注册

• 当前在epoll中注册的是listen描述符，当有请求链接时，会触发fd_become_readable，继而调用on_read方法
• 在十三章的1.1-4图中已经介绍了on_read方法是怎样被调用的，红框的grpc_fd_notify_on_read已经提前设置了该方法
• 箭头2：蓝色框中的代码描述了把accept描述放到不同的pollsets中，也就是放到不同的epoll模型中
• 箭头3：创建了新的epollfd，并把listenfd和acceptfd都注册到了新的epollfd中
• 箭头5：前面已经建立了accept描述符，后续会调用on_accept为接受数据做准备注意，在grpc_tcp_create中，有个vtable和tcp_handle_read会在后面用到，看代码时候不要忽略掉

继续看下箭头5on_accept函数的流程

• 把pollset放到了pollset_set中

继续看箭头3 on_handshake_done流程

• 15-3图只是一个简图，其中很多细节逻辑并没有标出来。只是为了说明主流程
• 注意蓝色的箭头，分别是write_action_begin_locked任务进入combiner_data里，read_action_locked任务进入clousre_list里，这样在后面grpc_core::ExecCtx::Get()->Flush()时候，就会执行到它们
• 可以对照第十四章的14-2图进行理解

当上面的accept工作完成后，epoll会继续等待具体请求内容的到来并处理，这一部分的工作模式与上面是一样的，由于个人精力问题，没有再去详细整理，欢迎小伙伴补充。抓住两个核心：tcp_send（tcp_posix.cc）、tcp_do_read（tcp_posix.cc），它们别分负责写和读

后面剩下的一点内容是DoWork，将在下面说明

2.2.2 DoWork

DoWork用来处理程序一开始时候注册的service逻辑

• DoWork的逻辑集中在CallData的Run函数中
• 处理完SayHello函数后，可以看到最后调用了tcp_send，发送了结果
• 16-1图中的MethodHandler来自第十章Register，见图16-2的右上角

GRPC C++部分的源码分析暂时写到这里，后面的分析比较粗糙，我自己也觉得不满意，但限于时间，只能先到这儿了。等闲下来时候或许会把缺失的细节补上。同时也非常欢迎有感兴趣的同学前来补充。