Boost.Asio网络库之io_service分析

io_service概述

几乎绝大多数用到Boost.Asio的代码里都会出现这样一个类: io_service
。它应该算是Asio库里的核心类了,其本质是一个任务队列,但又不仅仅是个任务队列。

基本结构

io_service是个接口类(ps:这里解释一下,这里说接口类并不是指类似java的interface类,而是指其是对下层类做了一个包装,全部功能都是调用
下层类来完成)。

class io_service : private noncopyable
{
private:
     typedef detail::io_service_impl impl_type;
    ...
}

上述代码中的impl_type即是我们所说的下层类,io_service的所有操作都是由它代为执行的。
这么说,为了实现跨平台,我们在io_service提供统一的操作接口,而不管平台的差异,impl_type的实现上分为两部分,

window系平台:win_iocp_io_service
非window系平台:task_io_service  

使用宏定义根据平台来决定将哪个类作为具体执行类,见源码

#if defined(BOOST_ASIO_HAS_IOCP)
    typedef class win_iocp_io_service io_service_impl;
    class win_iocp_overlapped_ptr;
#else
    typedef class task_io_service io_service_impl;
#endif

代码一目了然,不做赘述。
之前也学习过跨平台游戏引擎cocos2dx的部分源码,发现跨平台的开源库几乎都是类似的思想,用宏定义做到根据平台不同使用不同类来执行功能,在此之上提供接口,
屏蔽平台差异。
我们这里只讨论task_io_service对应的功能。

功能

上面我们说过,io_service类的本质是一个任务队列,所谓任务队列,其实就是一个队列容器而已,其内部元素为void型的函数,我们将这些函数抽象看待为任务
。(ps:既然是任务队列的模式,就当然会有锁的存在,而这个锁也被许多asio的使用者看做是眼中钉肉中刺,)
io_service提供了不少方法,在这里我们具体讨论最常用也是最核心的三个方法

run,run_one

run函数的功能是:执行队列的所有任务直到全部完成。
它应该是使用的最多的一个函数,因为当我们使用io_service注册异步事件后,需要执行run函数阻塞执行任务,否则程序可能会在任务未完成时就结束。
我们来看看其源码

std::size_t task_io_service::run(boost::system::error_code& ec)
{
    ec = boost::system::error_code();
    if (outstanding_work_ == 0)
    {
        stop();
        return 0;
    }

    thread_info this_thread;
    this_thread.private_outstanding_work = 0;
    thread_call_stack::context ctx(this, this_thread);

    mutex::scoped_lock lock(mutex_);

    std::size_t n = 0;
    for (; do_run_one(lock, this_thread, ec); lock.lock())
        if (n != (std::numeric_limits<std::size_t>::max)())
            ++n;
    return n;
}

outstanding_work_是一个原子变量,通过对它的值的修改来控制run函数是否直接结束。

run_one由名字就可想而知了,它只执行任务队列里的一个任务。
在执行任务时,如果有空闲线程,直接使用该线程去执行任务(领导者追随者模式),如果没有且监听事件的线程正在运行,则将阻塞时间变为0,即边监听边执行,待任务执行
完毕在阻塞在epoll_wait上。当任务执行完后,再将监听模式改为阻塞。

poll,poll_one

这两组函数和run/run_one函数的功能完全一样,只是run/run_one函数执行是阻塞的,而poll函数是非阻塞的,所以在
使用poll函数时要特别注意变量或对象的生命周期

post

stop

退出,停止工作

未完待续

如果本文对你有用,可以请作者喝杯茶~
0%