本文的测试环境是在MacOS，因此使用的多路复用的网络IO为kqueue而不是epoll，对应的IOLoop实例对象也是KQueueIOLoop。
在介绍Epoll模式的笔记中，最后写了一个tornado的使用epoll的例子。这个例子是如何工作的呢？下面来读一读tornado的源码。
启动一个tornado server很简单，只需要下面几code：
io_loop = tornado.ioloop.IOLoop.current()
callback = functools.partial(connection_ready, sock)
io_loop.add_handler(sock.fileno(), callback, io_loop.READ)
io_loop.start()
tornado.ioloop.IOLoop.current() 实际上是创建一个IO循环的对象，这里是KQueueIOLoop，Linux的系统则是EPollIOLoop。
下面是current的源码，该方法目的就是从local线程中获取KQueueIOLoop（如果存在的话，否则则新建一个）
@staticmethod
def current(instance=True):
current = getattr(IOLoop._current, "instance", None)
if current is None and instance:
return IOLoop.instance()
return current
程序首先判断 IOLoop._current对象（_current对象是一个线程local）的instance属性，如果没有current，则调用IOLoop.instance()方法创建一个IOLoop的实例作为currnet返回。由于tornado的包装，实际上IOLoop返回的并不是IOLoop的实例对象，而是KQueueIOLoop实例对象。
为什么IOLoop实例化的对象KQueueIOLoop呢？想知道答案就得揭开IOLoop.instance()神秘面纱，表面上看，该方法创建的IOLoop实例对象，并绑定到IOLoop._instance上。
@staticmethod
def instance():
if not hasattr(IOLoop, "_instance"):
with IOLoop._instance_lock:
if not hasattr(IOLoop, "_instance"):
# 新实例要经过两次check检查
IOLoop._instance = IOLoop()
return IOLoop._instance
IOLoop继承自Configurable基类，IOLoop 自身没有常见的初始化"构造函数"（init）。显然需要再查看Configurable基类。不看不知道，一看tornado的作者还真会玩。Configurable是一个设计很精巧的类，通过不同子类的继承来适配。基类在子类创建的时候做一些适配的事情。相比init, new称之为构造函数更准确。
class Configurable(object):
def __new__(cls, *args, **kwargs):
base = cls.configurable_base()
init_kwargs = {}
if cls is base:
# 通过调用configured_class方法，可以绑定 base.__impl_class 为epoll还是kqueue。
impl = cls.configured_class()
if base.__impl_kwargs:
init_kwargs.update(base.__impl_kwargs)
else:
impl = cls
init_kwargs.update(kwargs)
# impl 对象为对应的网络io模式，对于unix系统，因此这里是 kqueue方式，即位KQueueIOLoop类。
instance = super(Configurable, cls).__new__(impl)
# 通过initialize 方法，传接 并返回，这个就是上面current对象，即
instance.initialize(*args, **init_kwargs)
return instance
IOLoop在创建的时候，通过基类new方法调用子类的configurable_base和configurable_default适配不同子类的特性。这里通过IOLoop的configurable_default方法选择了unix系统的kqueue方式。
@classmethod
def configurable_default(cls):
if hasattr(select, "epoll"):
from tornado.platform.epoll import EPollIOLoop
return EPollIOLoop
if hasattr(select, "kqueue"):
# Python 2.6+ on BSD or Mac
from tornado.platform.kqueue import KQueueIOLoop
return KQueueIOLoop
from tornado.platform.select import SelectIOLoop
return SelectIOLoop
根据平台确定了impl为kqueue之后，将会通过new创建实例对象，就是这一步，创建了KQueueIOLoop而不是IOLoop的对象。Configurable自身不定义initialize。这里就调用了KQueueIOLoop的initialize方法。
class KQueueIOLoop(PollIOLoop):
def initialize(self, **kwargs):
super(KQueueIOLoop, self).initialize(impl=_KQueue(), **kwargs)
KQueueIOLoop的方法很简单，其中实现了一个_KQueue，这个类用于操作unix系统上的kqueue的网络io相关封装，例如注册事件，poll调用等。然后KQueueIOLoop带用其父类（PollIOLoop）的initialize方法。有没有发现，调用的控制权一直在各个父类基类中跳转。大概是 IOLoop -> Configurable -> IOLoop -> KQueueIOLoop -> PollOLoop -> IOLoop -> PolIOLoop。
class PollIOLoop(IOLoop):
def initialize(self, impl, time_func=None, **kwargs):
# 调用父类的IOLoop的initialize方法
super(PollIOLoop, self).initialize(**kwargs)
# _KQueue类
self._impl = impl
PollIOLoop继承自IOLoop，PollIOLoop调用其父类的initialize方法。此时调用make_current为None，因此又会调用IOLoop.current()的方法，怎么又是IOLoop.current？我们不就是从客户端逻辑（相对于库）调用这个方法进来的么？注意，不同于第一次客户端调用的时候，当时intances是True。也就是此时直接返回IOLoop._current.instance，前面正是因为current为None，才需要通过IOLoop的创建对象。当然此时current为None，即直接返回None。接下来自然运行make_current方法。
def initialize(self, make_current=None):
if make_current is None:
if IOLoop.current(instance=False) is None:
self.make_current()
elif make_current:
if IOLoop.current(instance=False) is None:
raise RuntimeError("current IOLoop already exists")
self.make_current()
make_current方法干点啥好呢？当然你肯定想到了，既然我们之前IOLoop.current方法是为了获取IOLoop._current.instance，并且一直为None，那么make_current正好填补这个空白，创建一个绑定就好嘛。
def make_current(self):
"""Makes this the `IOLoop` for the current thread.
将IOLoop实例对象绑定到local线程_current的instance属性。
"""
IOLoop._current.instance = self
的确，make_current把当前的类实例（KQueueIOLoop）创建并绑定。通过前面巧妙的设计，根据平台选择了网络io的模式。接下来还得根据io模式绑定IO监听事件。继续阅读PollIOLoop，可以发现通过add_handler方法喝Waker实现。
class PollIOLoop(IOLoop):
def initialize(self, impl, time_func=None, **kwargs):
...
# posix风格的文件读取操作，网络io本质也是文件操作
self._waker = Waker()
# 添加事件绑定，前面条用子类KQueueIOLoop的时候，传了_KQueue类
self.add_handler(self._waker.fileno(),
lambda fd, events: self._waker.consume(),
self.READ)
add_handler方法处理文件描述符，其中stack_context类通过wrap包装一个上下文类似的东西。具体数据结构没有仔细看，留待日后研究，总而言之，这个方法借助之前的_KQueue类注册网络io事件。
def add_handler(self, fd, handler, events):
fd, obj = self.split_fd(fd)
self._handlers[fd] = (obj, stack_context.wrap(handler))
self._impl.register(fd, events | self.ERROR)
此时，ioloop对象成功的创建。创建ioloop对象之后，server还不回启动，需要调用start启动。在启动之前，也需要通过add_hanndler绑定事件函数。至于start的工作原理，下回再研究。