接着上篇文章，今天继续探究 io_service。
上篇文章中我们知道了 io_service 是委托给 io_service_impl 实现的。好，废话不多我们来看看这个 io_service_impl 究竟是何方神圣。
namespace detail {
#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
class service_registry;
}
从命名空间上来看，这是个细节实现的地方。接着向下看，从宏定义中，我们可以很清楚的明白。如果存在 BOOST_ASIO_HAS_IOCP 那 io_service_impl就是 win_iocp_io_service，否则就是 task_io_service。我们先不管 win_iocp_io_service / task_io_service 。接着往下看 class service_registry。
service_registry 是不是很熟悉。这不就是 io_service 构造函数的实现吗？
io_service::io_service() : service_registry_(new boost::asio::detail::service_registry( *this, static_cast(0), (std::numeric_limits::max)())), impl_(service_registry_->first_service()){}
好，让我们定位到 service_registry 里。
template
service_registry 的构造函数需要 3 个参数。结合 io_service 的构造函数一起来看
*this，这个是io_service对象本身，作为所有服务的owner存在。
static_cast(0)，一个空指针对象，主要是为了模版参数类型推导。在service_registry的构造过程中，也会自动创建一个该类型的对象，作为第一个service对象。
(std::numeric_limits::max)()：提供一个最大的整数作为service构造时的参数——目前还没看到这个参数的用途。
service_registry 的构造函数
template< typename Service, typename Arg >
service_registry::service_registry(
boost::asio::io_service& o, Service*, Arg arg)
: owner_(o),
first_service_(new Service(o, arg)) {
boost::asio::io_service::service::key key;
init_key(key, Service::id);
first_service_->key_ = key;
first_service_->next_ = 0;
}
这个service_registry 是干什么的？我以后在的文章里是会详细讨论的。现在只要知道他是一个列表就好了。