thrift TNonblockingServer 源码剖析

关于调用流程，有几点需要着重解释的：
1.  监听线程只有一个，即#0号IO线程。 当新连接被分配给0号线程，该连接会进入状态机转移注册相应IO事件，其它IO线程会通过pipe通知直接进入状态转移；
2.  #0号IO线程与其它IO线程之间、IO线程与工作线程之间的通信是基于唯一的连接对象枢纽通过双向管道，即socketpair系统调用创建的unix local domain pipe进行通信，实现简洁高效；这种内部线程或进程间通信方式在其它网络库也很常见。
3.  IO事件均依赖libevent库注册相关事件事件回调，这样使得框架更多关注于如编解码、任务封装、具体的业务执行等，IO、work分工协作，增强通用性；
4.  对于连接状态机不再作具体分析，具体可参考源码，比较简单清晰；像我们自己实现的网络框架也是类似，展示一个连接获取任务到执行完毕的不同状态间的transition。
5. 任务（Task）封装是包含连接（TConnection）在内，而连接的创建包含了工作线程的执行体（TProcessor）且创建时机是在监听到新连接分配IO线程时，连接（长）的生命周期远长于Task，而IO线程在数据接收完成后进行Task封装，工作线程仅仅去执行Task对应的TProcessor而不关注其它额外如初始化工作等。
6.  所有工作线程是共享一个有工作线程池所管理的任务队列；个人认为这里可以修改为每个工作线程可独占一个任务队列，有主线程对task做负载分配（如轮询），可明显减少多个工作线程争用同一task队列的全局锁开销。
7.  对于工作线程较重客户端又急需回复确认时，需要做相应的任务分解和具体的业务执行优化，或者增加相关缓冲提高业务处理，或者业务上异步处理，否则会造成QPS下降。