GRPC-C++源码分析（十四）--Start续

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

14-1

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

14-2

• 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