总结 - phxrpc代码阅读(8)

写在前面

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

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

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

先补充一点 - 代码生成

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

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

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

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

工作流程 - 客户端

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

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

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

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

工作流程 - 服务端

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

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

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

more ...

RPC - phxrpc代码阅读(7)

前言

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

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

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

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

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

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

但是有以下的几个问题。

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

more ...

非阻塞TCP流和HttpClient - phxrpc代码阅读(6)

写在前面

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

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

非阻塞TCP流缓冲区 - UThreadTcpStreamBuf

这个其实没啥可讲的,传入一个socket,然后读写分别调用UThreadRecvUThreadSend,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 …

more ...

使用epoll驱动ucontext - phxrpc代码阅读(5)

用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()函数中看出 …

more ...

ucontext - phxrpc代码阅读(4)

写在前面

国庆假期过半,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操作还是比较耗性能的,所以虚函数多出来的几次内存寻址也并非不能接受 …

more ...

阻塞TCP流 - phxrpc代码阅读(3)

写在前面

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

BlockTcpStreamBuf

class BlockTcpStreamBuf继承自BaseTcpStreamBuf。其中重写了precvpsend两个函数,并且持有了一个文件描述符(file descriptor):socket_

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

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

if (BaseTcpUtils::SetNonBlock(sockfd, false …
more ...