boost::asio::io_service

最近在学习licode发现源码有使用到boost::asio::io_service,因此在网上找文章了解一下，顺便写篇博客记录

io_service 负责和操作系统打交道，等待所有异步操作的结束，然后为每一个异步操作调用其完成处
理程序。

例子（我们有3个异步操作，2个socket连接操作和一个计时器等待操作）：

有一个io_service实例和一个处理线程的单线程例子：
io_service service; // 所有socket操作都由service来处理
ip::tcp::socket sock1(service); // all the socket operations are handled by service
ip::tcp::socket sock2(service);
sock1.asyncconnect( ep, connect_handler);
sock2.async_connect( ep, connect_handler);
deadline_timer t(service, boost::posixtime::seconds(5));
t.async_wait(timeout_handler);
service.run();

有一个io_service实例和多个处理线程的多线程例子：
io_service service;
ip::tcp::socket sock1(service);
ip::tcp::socket sock2(service);
sock1.asyncconnect( ep, connect_handler);
sock2.async_connect( ep, connect_handler);
deadline_timer t(service, boost::posixtime::seconds(5));
t.async_wait(timeout_handler);
for ( int i = 0; i < 5; ++i)
boost::thread( run_service);
void run_service()
{
	service.run();
}

有多个io_service实例和多个处理线程的多线程例子：
io_service service[2];
ip::tcp::socket sock1(service[0]);
ip::tcp::socket sock2(service[1]);
sock1.asyncconnect( ep, connect_handler);
sock2.async_connect( ep, connect_handler);
deadline_timer t(service[0], boost::posixtime::seconds(5));
t.async_wait(timeout_handler);
for ( int i = 0; i < 2; ++i)
boost::thread( boost::bind(run_service, i));

void run_service(int idx)
{
	service[idx].run();
}

首先，要注意你不能拥有多个io_service实例却只有一个线程。下面的代码片段没有任何意义：

for ( int i = 0; i < 2; ++i)
service[i].run();

上面的代码片段没有意义是因为service[1].run()需要service[0].run()先结束。因此，所有由service[1]处理的异步操作都需要等待，这显然不是一个好主意。
在前面的3个方案中，我们在等待3个异步操作结束。为了解释它们之间的不同点，我们假设：过一会操作1完成，然后接着操作2完成。同时我们假设每一个完成处理程序需要1秒钟来完成执行。
在第一个例子中，我们在一个线程中等待三个操作全部完成，第1个操作一完成，我们就调用它的完成处理程序。尽管操作2紧接着完成了，但是操作2的完成处理程序需要在1秒钟后，也就是操作1的完成处理程序完成时才会被调用(串型)。
第二个例子，我们在两个线程中等待3个异步操作结束。当操作1完成时，我们在第1个线程中调用它的完成
处理程序。当操作2完成时，紧接着，我们就在第2个线程中调用它的完成处理程序（当线程1在忙着响应操作1的处理程序时，线程2空闲着并且可以回应任何新进来的操作）。（处理线程多不用等待）
在第三个例子中，因为操作1是sock1的connect，操作2是sock2的connect，所以应用程序会表现得像第二
个例子一样。线程1会处理sock1 connect操作的完成处理程序，线程2会处理sock2的connect操作的完成处理程序。然而，如果sock1的connect操作是操作1，deadline_timer t的超时操作是操作2，线程1会结束正在处理的sock1 connect操作的完成处理程序。因而，deadline_timer t的超时操作必须等sock1 connect操作的完成处理程序结束（等待1秒钟），因为线程1要处理sock1的连接处理程序和t的超时处理程序。

三个例子的总结：
第一种情况是非常基础的应用程序。因为是串行的方式，所以当几个处理程序需要被同时调用时，你通常会遇到瓶颈。如果一个处理程序需要花费很长的时间来执行，所有随后的处理程序都不得不等待。
第二种情况是比较适用的应用程序。他是非常强壮的——如果几个处理程序被同时调用了（这是有可能的），它们会在各自的线程里面被调用。唯一的瓶颈就是所有的处理线程都很忙的同时又有新的处理程序被调用。然而，这是有快速的解决方式的，增加处理线程的数目即可。
第三种情况是最复杂和最难理解的。你只有在第二种情况不能满足需求时才使用它。这种情况一般就是当你有成千上万实时（socket）连接时。你可以认为每一个处理线程（运行io_service::run()的线程）有它自己的select/epoll循环；它等待任意一个socket连接，然后等待一个读写操作，当它发现这种操作时，就执行。大部分情况下，你不需要担心什么，唯一你需要担心的就是当你监控的socket数
目以指数级的方式增长时（超过1000个的socket）。在那种情况下，有多个select/epoll循环会增加应用的响应时间。
如果你觉得你的应用程序可能需要转换到第三种模式，请确保监听操作的这段代码（调用io_service::run()的代码）和应用程序其他部分是隔离的，这样你就可以很轻松地对其进行更改。

IO模型
io_service对象是asio框架中的调度器，所有异步io事件都是通过它来分发处理的（io对象的构造函数中都需要传入一个io_service对象）。

 asio::io_service io_service;
 asio::ip::tcp::socket socket(io_service);

在asio框架中，同步的io主要流程如下：

1、应用程序调用IO对象成员函数执行IO操作
2、IO对象向io_service 提出请求.
3、io_service 调用操作系统的功能执行连接操作.
4、操作系统向io_service 返回执行结果.
5、io_service将错误的操作结果翻译为boost::system::error_code类型，再传递给IO对象.
6、如果操作失败,IO对象抛出boost::system::system_error类型的异常.
而异步IO的处理流程则有些不同：

1、应用程序调用IO对象成员函数执行IO操作
2、IO对象请求io_service的服务
3、io_service 通知操作系统其需要开始一个异步连接.
4、操作系统指示连接操作完成, io_service从队列中获取操作结果
5、应用程序必须调用io_service::run()以便于接收结果
6、调用io_service::run()后,io_service返回一个操作结果,并将其翻译为error_code,传递到事件回调函数中

o_service对象
io_service对象主要有两个方法——post和run：
1、post用于发布io事件，如timer，socket读写等，一般由asio框架相应对象调用，无需我们显式调用。
2、run用于监听io事件响应，并执行响应回调，对于异步io操作需要在代码中显式调用，对于同步io操作则由io对象隐式调用（并不是run函数，不过也是等待io事件）。
可见，io_service提供的是一个生产者消费者模型。在异步io操作中需要我们手动控制消费者，调用run函数，它的基本工作模式如下：

1、等待io事件响应，如果所有io事件响应完成则退出
2、等待到io事件响应后，执行其对应的回调
3、继续等待下一个io事件，重复1-2
从中可以看出，io_service是一个工作队列的模型。在使用过程中一般有如下几个需要注意的地方：
1、run函数在io事件完成后退出，导致后续基于该对象的异步io任务无法执行，由于io_service并不会主动调度线程，需要我们手动分配，常见的方式是给其分配一个线程，然后执行run函数。但run函数在io事件完成后会退出，线程会终止，后续基于该对象的异步io任务无法得到调度。
解决这个问题的方法是通过一个asio::io_service::work对象来守护io_service。这样，即使所有io任务都执行完成，也不会退出，继续等待新的io任务。

boost::asio::io_service io;
boost::asio::io_service::work work(io);
io.run();

2、回调在run函数的线程中同步执行，当回调处理时间较长时阻塞后续io响应
解决这个问题的方法有两种：1. 启动多线程执行run函数（run函数是线程安全的），2. 新启动一个线程（或通过线程池）来执行回调函数。一般来讲，如果回调处理事件不是特别短，应该使用在线程池中处理回调的方式。（最开始的2.3号例子）
3、回调在run函数的线程中同步执行，io事件较多的时候得不到及时响应
这个其实是性能问题了，在多核cpu上可以通过在多个线程中执行run函数来解决这一问题。这种方式也只能充分利用cpu性能，本身性能问题就不是光靠软件就能解决的。