在此之前,我们剖析了muduo库的各个模块,以及从使用muduo库搭建一个EchoServer,剖析了其内在的联系,分析了如何启动,连接建立,消息收发,连接断开的过程。到此,muduo库也算是一个小的完结了,不知道是否帮助到了大家~
但是muduo库依旧有很多思想值得我们去学习,所以在此做一个梳理总结,希望在以后的学习中,也可以借鉴起来。
one loop per thread
保证one loop per thread,就要满足以下两点:
- 一个线程只有一个EventLoop对象
使用__thread
关键字(__thread
变量每一个线程有一份独立实体,各个线程的值互不干扰。可以用来修饰那些带有全局性且值可能变,但是又不值得用全局变量保护的变量。)为了保证一个线程只有一个EventLoop对象,muduo定义了一个用该关键字修饰的EventLoop*变量,即__thread EventLoop *t_loopInThisThread = nullptr
,当某个子线程启动时,我们只需要在子线程执行函数(即)中构造一个EventLoop对象,EventLoop的构造函数会把t_loopInThisThread
初始化为this
,指向这个对象。这样一来,如果该线程中再次创建一个EventLoop对象时,指针不为空就会在其构造函数中终止程序。
if(t_loopInThisThread)
{
LOG_FATAL("Another EvnetLoop %p exists in this thread %d \n",t_loopInThisThread, threadId_);
}
else
{
t_loopInThisThread = this;
}
- 不该跨线程调用的函数不会跨线程调用
muduo网络库保证one loop per thread的核心就是:每个线程(EventLoop)都准备一个待执行队列pendingFunctors_
,用于存储待执行函数,当其他线程需要调用某个不能跨线程调用的函数时(比如TcpConnection::sendInLoop
、TcpConnection::shutdownInLoop
、TcpConnection::connectEstablished
,因为他们都涉及到对fd的操作),只需要把该函数通过runInLoop或者queInLoop加入到本线程的待执行队列中,然后由本线程从队列中取出该函数并执行。例如:TcpConnection::sendInLoop()
,在TcpConnection::send()
调用TcpConnection::sendInLoop()
发送数据之前,会先判断调用send函数的线程和TcpConnection所属loop_
绑定的线程是否是同一个
if(loop_->isInLoopThread())
{
sendInLoop(buf.c_str(),buf.size());
}
else
{
loop_->runInLoop(std::bind(&TcpConnection::sendInLoop
, this
, buf.c_str()
, buf.size()
));
}
//EventLoop.h
bool isInLoopThread() const { return threadId_ == CurrentThread::tid(); }
threadId_
是调用createEventfd()
函数,底层调用eventfd
得到的,这个在三大核心组件之EventLoop类描述过。
- 如果满足,说明没有跨线程调用
TcpConnection::send
,因此可以直接调用TcpConnection::sendInLoop
发送数据; - 如果不满足,则调用
EventLoop::runInLoop
,在EventLoop::runInLoop
中,如果满足isInLoopThread()
,直接执行回调函数cb,否则,就调用EventLoop::queueInLoop
把cb
加入到待执行队列pendingFunctors_
中,并在必要的时候通过wakeup()
唤醒EventLoop绑定的线程。
- 如何唤醒呢?
谁会执行pendingFunctors_
呢?EventLoop::doPendingFunctors()
,那谁调用它呢?EventLoop::loop()
。在这个函数中,如果子线程管理的fd上没有任何事件发生,那么该线程就会一直阻塞在epoller_->poll
函数,无法执行doPendingFunctors函数了。所以是需要唤醒的。在构造EventLoop实例的时候,每一个EventLoop都有一个wakeupFd_
,同样把该fd封装成Channel,变成wakeupChannel_
EventLoop::EventLoop()
:省
, wakeupFd_(createEventfd())
, wakeupChannel_(new Channel(this,wakeupFd_))
- 当在
queueInLoop
函数中调用wakeup()
时,就会在wakeupFd_
上写入一个八字节的数据,这样Poller
就会检测到wakeupFd_
可读,于是就解除了阻塞,进而执行doPendingFunctors
,即取出pendingFunctors_
的函数执行相应的回调。
Channel中的tie_
如果没有tie_
,当客户端主动关闭连接时,服务器上该连接对应的sockfd的Channel会调用Channel::handleEvent()
来关闭连接,从而释放TcpConnection,进而Channel对象也会析构,这就造成了Channel::handleEvent()还只执行到一半,Channel就已经被析构了,引发不可预测的后果。为了避免这个问题,muduo库使用弱指针tie_
绑定到TcpConnection的共享指针上TcpConnectionPtr
,如果tie_
能够被转化为强共享指针,这就延长了TcpConnection的生命周期,使之长过Channel::handleEvent(),这样一来,Channel::handleEvent()来关闭连接时,Channel::handleEvent
的guard
变量依然持有一份TcpConnection,使其的引用计数不会减为0,去执行Channel::handleEventWithGuard()
函数,也保证了在触发TcpConnection关闭机制后,先让TcpConnection把数据发送完再释放TcpConnection对象的资源,也就是说Channel不会在执行完Channel::handleEvent()之前被析构。这一部分我们在[muduo网络库]——EchoServer之连接断开(剖析muduo网络库核心部分、设计思想)也剖析过。
保证关闭连接时数据不会漏收
首先要强调的一点是:muduo永远都是被动关闭连接:即等待对方关闭后,自己才关闭连接,即使muduo主动关闭连接,也只关闭自己的写端,等对方关闭后,再关闭自己的读端。所以这种关闭连接的方式要求对方read到0字节后(read到0字节表示对方已经关闭了),服务器也会调用TcpConnection::handleClose()
关闭连接。为什么是关闭写端,我们在TcpConnection类也进行了分析。
代码地址:https://github.com/Cheeron955/mymuduo/tree/master