写在前面

这应该是phxrpc代码阅读系列正文的最后一篇。通过阅读代码，发现了自己在知识上的若干不足。

临渊羡鱼，不如退而结网。接下来可能会在网络编程方面再下一点工夫。请大家期待下一个系列吧。

其实真没人读，我就是在骗自己。

先补充一点 - 代码生成

protobuf并不包含RPC的实现，但是它可以声明rpc。客户端和服务端需要实现RPC接口，来实现通信。

phxrpc使用proto文件来定义接口，然后解析并使用代码模板进行生成。

这里我们不讨论代码生成的细节，因为pb实在太过流行，代码生成的方法也有不少的流派。并且用C++来做代码生成，真心不是我的菜。

想了解更多，可以参考这篇博客。

工作流程 - 客户端

客户端与服务器的通信有如下的特点：

1. 连接少
2. 负载少
3. 通信的主动方

所以，所有的网络交互相关的内容可以托管给网络库中的协程。每个协程主动运行一段时间后，主动放弃CPU时间，将控制权交还给主控制流的epoll。

所以协程中不能有CPU密集的运算，幸好面对开发者，phxrpc并不暴露内部函数，而是将CPU密集的运算分配给工作线程来完成。

工作流程 - 服务端

服务器的通信有以下的特点：

1. 连接多
2. 负载多
3. 通信的被动方
4. 响应时间敏感

这里说一下响应时间的问题 …

前言

看了这么久代码，终于我们要接近phxrpc的核心部分了。

但是出人意料的是，rpc部分并没有过多的概念和magic trick。而且因为ucontext已经被封装好了，所以在rpc里的操作，可以完全按照同步的写法来搞，开发者们不需要切换同步异步的思维模式，就可以在底层的封装之上，做自己想做的事了。

线程安全(?)的队列 - ThreadQueue

我不知道开发者为啥要起ThdQueue这样令人迷惑的名字，这种诡异的命名风格贯穿了整个代码。咋一看这个类是maintain一堆线程的，类似于线程池，但其实这个类就是一个BlockingQueue的实现。

之后，这个队列有三种操作，push、pluck和break_out。push操作不用多说，pluck对应的我们所理解的pop操作，即从队列中弹出元素（pluck这个词貌似是从grpc里面来的，那我就不吐槽了，毕竟Google爸爸）。

更令人疑惑的是break_out这个操作。从代码来看，像是清空队列，并且在dtor中也显式的调用了这个函数。

但是有以下的几个问题。

一，break_out_是一个bool变量，且在不同线程间共享，问题在于这个变量可能被cache住，直接访问可能会造成非预期的结果，可能需要 …

写在前面

其实这点东西有点鸡肋。因为TCP流在前面已经讲过，难点在于“流”和“流缓冲区”部分。而HttpClient只是TCP流的一个应用，代码不多，且重点在于HTTP协议的调教上面。

不过因为前面有写阻塞TCP流，还是前后呼应，把非阻塞TCP流也小小的讲解一下。顺便饶一段HttpClient的讲解，算是充实一下内容吧。

非阻塞TCP流缓冲区 - UThreadTcpStreamBuf

这个其实没啥可讲的，传入一个socket，然后读写分别调用UThreadRecv和UThreadSend，IO复用和协程切换的复杂操作都被封装在里面了。剩下的操作都由基类函数来解决。

非阻塞TCP流 - UThreadTcpStream

确实没啥可说的，你们自己去读代码吧。。。

非阻塞TCP流和阻塞TCP流的区别是~~它不阻塞~~，在阻塞TCP流中，我们传入的是一个TCP流，而非阻塞TCP流传入的是一个协程调度器和一个TCP流。

这个很好理解，一个阻塞流自然会占满一个线程的IO和CPU —— 在阻塞流IO读写时，CPU空闲；在CPU忙时，IO空闲。

而非阻塞流会将自己IO wait的时间托管给epoll，把剩下的时间用于CPU计算（和一些overhead上）。所以一个线程可以handle多个socket，协程调度器就是必须的了。之后的读写操作就交由我们前面讨论过的epoll和ucontext协程来共同完成了。

HttpClient …

用pipe叫醒你 — EpollNotifier

class EpollNotifier类型封装了一个使用pipe传递信号的Notifier类。

Run()函数（其实我觉得叫Register或Activate会更好）首先声明了两个单向的pipe：pipe_fds_，从文档中我们可以知道pipe_fds_[0]是读管道，而pipe_fds_[1]是写管道。这里有一丁点反直觉，就是pipe拿了两个fd，但是仍旧是单工的。

然后将读fd设为O_NONBLOCK以供epoll调度，最后将Func()函数传入scheduler_中。

这里跑个题，想起了当年我大一的时候上过的通信导论的选修课。那会我还没有沉迷代码，还是一个积极乐观好好学习的新时代大学生。自从开始写了代码，人就越来越废物了，连女朋友都找不到了。
年轻人们啊，有饭辙干点啥都行，千万别写码啊。

Func()函数做的事情很简单，就是从管道里尝试poll一段数据，拿到数据后直接扔掉。因为管道里传来的数据并没有实际意义，这样设计的主要意义在于唤醒epoll。

我们可以从Notify()函数中看出 …

写在前面

国庆假期过半，phxrpc的代码阅读大概要小小告一段落啦。因为这两天还要读工作相关的代码，以及最后几天还有一次短途旅行。

所以非阻塞TCP流可能要留到下一篇了，这一篇只涉及非阻塞TCP流使用到的ucontext协程库，及其使用的一些框架代码。

161013更新：这点破东西写到今天才写完，GG。

什么是ucontext

"Subroutines are special cases of ... coroutines." –Donald Knuth.

首先我们来看一下，什么是线程。线程是进程内一条执行流的状态，包含了硬件状态（硬件计数器，寄存器，条件码等）和堆栈中的数据。

线程通常只有一个入口和一个出口。当线程返回时，线程的生命周期也结束了。所以，通常线程的执行由内核调度。

协程的定义与线程类似，也是硬件状态+堆栈的状态组合。但是与线程不同的是，协程可以有多个出口。可以通过yield来暂停自己，调用其它协程。再次启动时，会从上次挂起的地方继续运行。

phxrpc中的ucontext

phxrpc提供了system和boost两种ucontext的实现，所以提供了一个uthread_context_base的基类。其实在这里我是有一点怀疑虚函数的性能的，不过好在协程的切换以及网络IO操作还是比较耗性能的，所以虚函数多出来的几次内存寻址也并非不能接受 …

写在前面

phxrpc的流（stream和streambuf）与网络访问其实是耦合在一起的，所以本文可以结合着第一篇笔记一起来看。虽然我非常想吐槽这种强耦合性的设计，但是我决定还是好好理解phxrpc的设计之后。。。攒一波大的：）

BlockTcpStreamBuf

class BlockTcpStreamBuf继承自BaseTcpStreamBuf。其中重写了precv和psend两个函数，并且持有了一个文件描述符(file descriptor)：socket_。

precv和psend直接调用了<sys/socket.h>中的recv(2)和send(2)，并没有其它操作。

网络相关的操作，则由class BlockTcpStream来负责。BlockTcpStreamBuf只负责IO部分。

if (BaseTcpUtils::SetNonBlock(sockfd, false …

写在前面

phxrpc使用了协程(ucontext)和IO复用技术(epoll)来实现网络通信。定时器在其中起到了非常重要的作用。下面我们就来分析一下phxrpc的timer.[h|cpp]中的代码。

system_clock vs steady_clock

system_clock和steadly_clock都是来自<chrono>库，都是用来获取当前时间的。

system_clock用来从系统时钟获取时钟时间(wall clock time)，而steadly_clock获取的是时钟tick，而且保证随着时间的推移，时钟tick数不会变小。

然而实际上，在某些系统下，这两个时钟的实现是一致的。详细信息可以参考这里。

注：在clang++ 4.2.1, g++ 5.4 下实验，这两个时钟是不同的。所以个人认为在这里最好不要做任何无意义的假设。

几毫秒的安睡

void …

写在前面

phxrpc是微信团队开源的一个轻量级RPC框架。

我对RPC这些东西了解不多，看到phxrpc的代码相对简单，而且还在初步开发阶段（在本文写作时，版本号是0.8）。所以想读一读，提高一下姿势水平。

就是这样。

自定义stream buffer

network/socket_stream_base.[h|cpp]中的class BaseTcpStreamBuf继承了std::streambuf，自定义了一个流缓冲区，用于接收/发送TCP数据包。

这个用法比较新颖（或者是我见识少），网上的资料也不多。这里翻译一篇介绍文章，学习一下新姿势。

A beginner's guide to writing a custom stream buffer

流(streams)是STL中提供的一个重要的抽象概念。著名的“Hello world”程序，便是使用了std …