muduo源码分析--我对muduo的理解

分为几个模块 EventLoop、TcpServer、Acceptor、TcpConnection、Channel等

对于EventLoop来说：

他只关注里面的主驱动力，EventLoop中只关注poll,这类系统调用使得其成为Reactor模式，EventLoop中有属于这个loop的所有Channel，这个loop属于哪一个Server.

 

几个类存在的意义：

从应用层使用的角度来看，用户需要初始化一个EventLoop，然后初始化一个TcpServer(当然也可以自定义个TcpServer，自定义数据处理函数需要注册到TcpServer内),然后调用TcpServer的start函数，然后调用EventLoop的loop()函数。整个用户层的使用流程就是这样的！

从用户层的应用方法来解析Muduo库的设计思想：

首先来看TcpServer这个类，从名字来看，它是一个服务器，里面肯定需要有一个用于监听某个地址的套接字，这个是Acceptor类，这是由TcpServer引出的第一个类，在Acceptor类中封装了监听套接字，Acceptor负责了一个socketfd,这个socketfd就是一个监听套接字。当这个套接字上有可读事件时，调用了Acceptor的handleRead函数，此函数的内部就是accept()系统调用了，函数返回产生了一个连接套接字，紧接着就是调用Acceptor中的回调函数newConnectionCallback_，那么这个回调是谁注册的呢？肯定是谁拥有Acceptor谁就负责初始化Acceptor中的newConnectionCallback_回调喽！那么就是TcpServer负责注册！在进行TcpServer初始化时调用Acceptor中的setNewConnectionCallback()函数将newConnection赋值给newConnectionCallback_。也就是说，在Acceptor中一旦accept()系统调用成功返回就立马调用newConnection函数。

到目前为止，遗留下了以下几个问题：

1、  Acceptor中的handleRead()函数是什么时候被调用的！

2、  newConnecion虽说属于TcpServer，但是newConnection函数的作用是创建了一个类！这个类的作用也是举足轻重!

 

接下来介绍下由TcpServer引出的Acceptor类：

首先这个类是属于内部类。既然这个类是管理监听套接字的，那么这个监听套接字的生命周期就是由Acceptor类来管理。这个套接字在Acceptor就是Socket，同时也有一个EventLoop指针，表明这个Acceptor属于某一个EventLoop（因为Acceptor依赖于某一个TcpSever,同时TcpServe和EventLoop是有依赖关系的）。同时还有一个newConnectionCallback_函数，这个函数是在TcpServer初始化的时候被赋值的。Listening_表示当前这个监听套接字的状态，idleFd_是一个输出错误的描述符。这里还有一个新的类—Channel！这个类在整个库中起着桥接的作用，整个这个类将有些东西单独提取，是的其他各个类的功能更加单一，关于这个类的介绍不在这里，毕竟Acceptor类是一个内部类，如果这个一个庞大的类由内部类引出，显得不够重视！呵呵！这里暂时雪藏Channel类！

关于Acceptor类的接口，只有很少的三个：

其中一个是setNewConnectionCallback，由于Acceptor类属于TcpServer类，所以调用合格函数的肯定是属于Acceptor的所有者，也就是TcpServer类，这个函数在TcpServer的构造函数中被调用，将newConnectionCallback_函数赋值为newConnection，已经说过了，有点啰嗦了！呵呵！另外一个就是listen()函数，从感觉上来看，这个是使得Acceptor类中的acceptSocket_处于监听状态的函数，暂时记住这个函数，尤其是这个函数中的最后一句，这事欠下的有待解决的问题！

 

有待解决的问题：

1、  在Acceptor中的listen()函数中，属于Channel类中的enableReading()是干什么的？

2、  Acceptor的listen()何时被调用！

到此需要记住的几点：

监听套接字是单独的类Acceptor，是脱离TcpServer类存在的一个类！

同时TcpServer类中不包含任何一个套