异步 阻塞 多路IO

Posted 2021-03-09 xc2020

协程

协程，又称微线程，纤程。英文名Coroutine。一句话说明什么是线程：协程是一种用户态的轻量级线程。协程拥有自己的寄存器上下文和栈。协程调度切换时，将寄存器上下文和栈保存到其他地方，在切回来的时候，恢复先前保存的寄存器上下文和栈。
因此：协程能保留上一次调用时的状态（即所有局部状态的一个特定组合），每次过程重入时，就相当于进入上一次调用的状态，换种说法：进入上一次离开时所处逻辑流的位置。

协程的概念很早就提出来了，但直到最近几年才在某些语言（如Lua）中得到广泛应用。

• 子程序，或者称为函数，在所有语言中都是层级调用，比如A调用B，B在执行过程中又调用了C，C执行完毕返回，B执行完毕返回，最后是A执行完毕。所以子程序调用是通过栈实现的，一个线程就是执行一个子程序。子程序调用总是一个入口，一次返回，调用顺序是明确的。
• 而协程的调用和子程序不同。协程看上去也是子程序，但执行过程中，在子程序内部可中断，然后转而执行别的子程序，在适当的时候再返回来接着执行。注意，在一个子程序中中断，去执行其他子程序，不是函数调用，有点类似CPU的中断。比如子程序A、B：

def A():
    print '1'
    print '2'
    print '3'

def B():
    print 'x'
    print 'y'
    print 'z'

利用协程结果则可能为：

1
2
x
y
3
z

协程其实也是单线程！

协程的好处：

1. 最大的优势就是协程极高的执行效率。因为子程序切换不是线程切换，而是由程序自身控制，因此，没有线程切换的开销，和多线程比，线程数量越多，协程的性能优势就越明显。
2. 第二大优势就是不需要多线程的锁机制，因为只有一个线程，也不存在同时写变量冲突，在协程中控制共享资源不加锁，只需要判断状态就好了，所以执行效率比多线程高很多。
   因为协程是一个线程执行，那怎么利用多核CPU呢？最简单的方法是多进程+协程，既充分利用多核，又充分发挥协程的高效率，可获得极高的性能。Python对协程的支持还非常有限，用在generator中的yield可以一定程度上实现协程。虽然支持不完全，但已经可以发挥相当大的威力了。

缺点：

1. 无法利用多核资源：协程的本质是个单线程,它不能同时将单个CPU的多个核用上,协程需要和进程配合才能运行在多CPU上.当然我们日常所编写的绝大部分应用都没有这个必要，除非是cpu密集型应用。
2. 进行阻塞（Blocking）操作（如IO时）会阻塞掉整个程序

```import time
import queue
def consumer(name):
print("--->starting eating baozi...")
while True:
new_baozi = yield
print("[%s] is eating baozi %s" % (name,new_baozi))
#time.sleep(1)

def producer():

r = con.__next__()
r = con2.__next__()
n = 0
while n < 5:
    n +=1
    con.send(n)
    con2.send(n)
    print("33[32;1m[producer]33[0m is making baozi %s" %n )

if name == ‘main‘:
con = consumer("c1")
con2 = consumer("c2")
p = producer()
```

那么这算不算协程？

1. 必须在只有一个单线程里实现并发
2. 修改共享数据不需加锁
3. 用户程序里自己保存多个控制流的上下文栈
4. 一个协程遇到IO操作自动切换到其它协程

基于上面这4点定义，我们刚才用yield实现的程并不能算是合格的线程，因为它有一点功能没实现，哪一点呢？

greenlet

The greenlet package is a spin-off of Stackless, a version of CPython that supports micro-threads called "tasklets". Tasklets run pseudo-concurrently /?su?do?/ (typically in a single or a few OS-level threads) and are synchronized with data exchanges on "channels".

任务集在一个或者几个系统线程中，同步数据交换在几个频道上，用着 假并行！

A "greenlet", on the other hand, is a still more primitive notion of micro-thread with no implicit scheduling; coroutines, in other words. This is useful when you want to control exactly when your code runs. You can build custom scheduled micro-threads on top of greenlet; however, it seems that greenlets are useful on their own as a way to make advanced control flow structures. For example, we can recreate generators; the difference with Python‘s own generators is that our generators can call nested functions and the nested functions can yield values too. Additionally, you don‘t need a "yield" keyword. See the example in tests/test_generator.py.

Greenlets are provided as a C extension module for the regular unmodified interpreter.

Greenlets are lightweight coroutines for in-process concurrent programming.
There are several libraries that use Greenlet as a more flexible alternative to Python’s built in coroutine support:

1. Concurrence(估计不更新了)
2. Eventlet
3. Gevent

那么怎么用？
Introduction

一、介绍

　　A “greenlet” is a small independent pseudo-thread. Think about it as a small stack of frames; the outermost (bottom) frame is the initial function you called, and the innermost frame is the one in which the greenlet is currently paused. You work with greenlets by creating a number of such stacks and jumping execution between them. Jumps are never implicit: a greenlet must choose to jump to another greenlet, which will cause the former to suspend and the latter to resume where it was suspended. Jumping between greenlets is called “switching”.

　　When you create a greenlet, it gets an initially empty stack; when you first switch to it, it starts the run a specified function, which may call other functions, switch out of the greenlet, etc. When eventually the outermost function finishes its execution, the greenlet’s stack becomes empty again and the greenlet is “dead”. Greenlets can also die of an uncaught exception.

　　一个 “greenlet” 是一个小型的独立伪线程。可以把它想像成一些栈帧，栈底是初始调用的函数，而栈顶是当前greenlet的暂停位置。你使用greenlet创建一堆这样的堆栈，然后在他们之间跳转执行。跳转必须显式声明的：一个greenlet必须选择要跳转到的另一个greenlet，这会让前一个挂起，而后一个在此前挂起处恢复执行。不同greenlets之间的跳转称为切换(switching) 。

　　当你创建一个greenlet时，它得到一个开始时为空的栈；当你第一次切换到它时，它会执行指定的函数，这个函数可能会调用其他函数、切换跳出greenlet等等。当最终栈底的函数执行结束出栈时，这个greenlet的栈又变成空的，这个greenlet也就死掉了。greenlet也会因为一个未捕捉的异常死掉。

　　例如：

复制代码

from greenlet import greenlet

def test1():
... print 12
... gr2.switch()
... print 34
...
def test2():
... print 56
... gr1.switch()
... print 78
...
gr1 = greenlet(test1)
gr2 = greenlet(test2)
gr1.switch()
12
56
34
复制代码

　　The last line jumps to test1, which prints 12, jumps to test2, prints 56, jumps back into test1, prints 34; and then test1 finishes and gr1 dies. At this point, the execution comes back to the original gr1.switch() call. Note that 78 is never printed.

　　最后一行首先跳转到greenlet gr1 执行其指定的函数 test1 ，这里 test1没有参数，因此 gr1.switch() 也不需要指定参数。 test1打印12，然后跳转到 test2 ，打印56，然后跳转回 test1 ，打印34，最后 test1 结束执行， gr1 死掉。这时执行会回到最初的 gr1.switch() 调用。注意，78是不会被打印的。

补充：

　　该部分关于greenlet和eventlet的介绍摘自《Python几种并发实现方案的性能比较》

　　greenlet不是一种真正的并发机制，而是在同一线程内，在不同函数的执行代码块之间切换，实施“你运行一会、我运行一会”，并且在进行切换时必须指定何时切换以及切换到哪。greenlet的接口是比较简单易用的，但是使用greenlet时的思考方式与其他并发方案存在一定区别。

　　线程/进程模型在大逻辑上通常从并发角度开始考虑，把能够并行处理的并且值得并行处理的任务分离出来，在不同的线程/进程下运行，然后考虑分离过程可能造成哪些互斥、冲突问题，将互斥的资源加锁保护来保证并发处理的正确性。

　　greenlet则是要求从避免阻塞的角度来进行开发，当出现阻塞时，就显式切换到另一段没有被阻塞的代码段执行，直到原先的阻塞状况消失以后，再人工切换回原来的代码段继续处理。因此，greenlet本质是一种合理安排了的串行，实验中greenlet方案能够得到比较好的性能表现，主要也是因为通过合理的代码执行流程切换，完全避免了死锁和阻塞等情况（执行带屏幕输出的ring_greenlet.py我们会看到脚本总是一个一个地处理消息，把一个消息在环上从头传到尾之后，再开始处理下一个消息）。因为greenlet本质是串行，因此在没有进行显式切换时，代码的其他部分是无法被执行到的，如果要避免代码长时间占用运算资源造成程序假死，那么还是要将greenlet与线程/进程机制结合使用（每个线程、进程下都可以建立多个greenlet，但是跨线程/进程时greenlet之间无法切换或通讯）。

　　粗糙来讲，greenlet是“阻塞了我就先干点儿别的，但是程序员得明确告诉greenlet能先干点儿啥以及什么时候回来”；greenlet应该是学习了Stackless的上下文切换机制，但是对底层资源没有进行适合并发的改造。并且实际上greenlet也没有必要改造底层资源的并发性，因为它本质是串行的单线程，不与其他并发模型混合使用的话是无法造成对资源的并发访问的。

　　greenlet 封装后的 eventlet 方案
　　eventlet 是基于 greenlet 实现的面向网络应用的并发处理框架，提供“线程”池、队列等与其他 Python 线程、进程模型非常相似的 api，并且提供了对 Python 发行版自带库及其他模块的超轻量并发适应性调整方法，比直接使用 greenlet 要方便得多。并且这个解决方案源自著名虚拟现实游戏“第二人生”，可以说是久经考验的新兴并发处理模型。其基本原理是调整 Python 的 socket 调用，当发生阻塞时则切换到其他 greenlet 执行，这样来保证资源的有效利用。需要注意的是：

eventlet 提供的函数只能对 Python 代码中的 socket 调用进行处理，而不能对模块的 C 语言部分的 socket 调用进行修改。对后者这类模块，仍然需要把调用模块的代码封装在 Python 标准线程调用中，之后利用 eventlet 提供的适配器实现 eventlet 与标准线程之间的协作。
再有，虽然 eventlet 把 api 封装成了非常类似标准线程库的形式，但两者的实际并发执行流程仍然有明显区别。在没有出现 I/O 阻塞时，除非显式声明，否则当前正在执行的 eventlet 永远不会把 cpu 交给其他的 eventlet，而标准线程则是无论是否出现阻塞，总是由所有线程一起争夺运行资源。所有 eventlet 对 I/O 阻塞无关的大运算量耗时操作基本没有什么帮助。

Parents

二、父greenlet

　　Let’s see where execution goes when a greenlet dies. Every greenlet has a “parent” greenlet. The parent greenlet is initially the one in which the greenlet was created (this can be changed at any time). The parent is where execution continues when a greenlet dies. This way, greenlets are organized in a tree. Top-level code that doesn’t run in a user-created greenlet runs in the implicit “main” greenlet, which is the root of the tree.

　　In the above example, both gr1 and gr2 have the main greenlet as a parent. Whenever one of them dies, the execution comes back to “main”.

　　Uncaught exceptions are propagated into the parent, too. For example, if the above test2() contained a typo, it would generate a NameError that would kill gr2, and the exception would go back directly into “main”. The traceback would show test2, but not test1. Remember, switches are not calls, but transfer of execution between parallel “stack containers”, and the “parent” defines which stack logically comes “below” the current one.

　　现在看看一个greenlet结束时执行点去哪里。每个greenlet拥有一个父greenlet。每个greenlet最初在其父greenlet中创建(不过可以在任何时候改变)。当子greenlet结束时，执行位置从父greenlet那里继续。这样，greenlets之间就被组织成一棵树，顶级的代码并不在用户创建的 greenlet 中运行，而是运行在一个主greenlet中，也就是所有greenlet关系图的树根。

　　在上面的例子中， gr1 和 gr2 都把主greenlet作为父greenlet。任何一个死掉，执行点都会回到主greenlet。

　　未捕获的异常会传递给父greenlet。如果上面的 test2 包含一个打印错误(typo)，会生成一个 NameError 而杀死 gr2 ，然后异常被传递回主greenlet。traceback会显示 test2 而不是 test1 。记住，切换不是调用，而是执行点在并行的栈容器间交换，而父greenlet定义了这些栈之间的先后关系。

Instantiation

三、实例化

greenlet.greenlet

　　is the greenlet type, which supports the following operations:

　　是一个 greenlet 类型，支持如下操作：

greenlet(run=None, parent=None)

　　Create a new greenlet object (without running it). run is the callable to invoke, and parent is the parent greenlet, which defaults to the current greenlet.

　　创建一个greenlet对象，不执行。run是这个greenlet要执行的回调函数，而parent是父greenlet，缺省为当前greenlet。

greenlet.getcurrent()

　　Returns the current greenlet (i.e. the one which called this function).

　　返回当前greenlet，也就是谁在调用这个函数。

greenlet.GreenletExit

　　This special exception does not propagate to the parent greenlet; it can be used to kill a single greenlet.

　　这个特定的异常不会波及到父greenlet，它用于干掉一个greenlet。

　　The greenlet type can be subclassed, too. A greenlet runs by calling its run attribute, which is normally set when the greenlet is created; but for subclasses it also makes sense to define a run method instead of giving a run argument to the constructor.

　　greenlet 类型可以被继承。一个greenlet通过调用其 run 属性执行，就是创建时指定的那个。对于子类，可以定义一个 run() 方法，而不必严格遵守在构造器中给出 run 参数。

Switching

四、在greenlets间切换

　　Switches between greenlets occur when the method switch() of a greenlet is called, in which case execution jumps to the greenlet whose switch() is called, or when a greenlet dies, in which case execution jumps to the parent greenlet. During a switch, an object or an exception is “sent” to the target greenlet; this can be used as a convenient way to pass information between greenlets. For example:

　　greenlet之间的切换发生在greenlet的 switch 方法被调用时，这会让执行点跳转到greenlet的 switch 被调用处。或者在greenlet死掉时，跳转到父greenlet那里去。在切换时，一个对象或异常被发送到目标greenlet。这可以作为两个greenlet之间传递信息的方便方式。

　　例如:

复制代码

def test1(x, y):
... z = gr2.switch(x+y)
... print z
...
def test2(u):
... print u
... gr1.switch(42)
...
gr1 = greenlet(test1)
gr2 = greenlet(test2)
gr1.switch("hello", " world")
hello world
42
复制代码

　　This prints “hello world” and 42, with the same order of execution as the previous example. Note that the arguments of test1() and test2() are not provided when the greenlet is created, but only the first time someone switches to it.

　　Here are the precise rules for sending objects around:

　　这会打印出 “hello world” 和42，跟前面的例子的输出顺序相同。注意 test1() 和 test2() 的参数并不是在 greenlet 创建时指定的，而是在第一次切换到这里时传递的。

　　这里是精确的调用方式:

g.switch(*args, **kwargs)

　　Switches execution to the greenlet g , sending it the given arguments. As a special case, if g did not start yet, then it will start to run now.

　　切换到执行点greenlet g，将这里指定的参数发送这个greenlet。在特殊情况下，如果g还没有启动，就会让它启动；

Dying greenlet

五、垂死的greenlet

　　If a greenlet’s run() finishes, its return value is the object sent to its parent. If run() terminates with an exception, the exception is propagated to its parent (unless it is a greenlet.GreenletExit exception, in which case the exception object is caught and returned to the parent).

　　如果一个greenlet的 run()结束了，他会返回值是返回给父greenlet的对象。如果 run()是异常终止的，异常会传播到父greenlet(除非是 greenlet.GreenletExit 异常，这种情况下异常会被捕捉并返回到父greenlet)。

　　Apart from the cases described above, the target greenlet normally receives the object as the return value of the call to switch() in which it was previously suspended. Indeed, although a call to switch() does not return immediately, it will still return at some point in the future, when some other greenlet switches back. When this occurs, then execution resumes just after the switch() where it was suspended, and the switch() itself appears to return the object that was just sent. This means that x = g.switch(y) will send the object y to g, and will later put the (unrelated) object that some (unrelated) greenlet passes back to us into x.

　　Note that any attempt to switch to a dead greenlet actually goes to the dead greenlet’s parent, or its parent’s parent, and so on. (The final parent is the “main” greenlet, which is never dead.)

　　除了上面的情况外，目标greenlet会接收到发送来的对象作为 switch() 的返回值。虽然 switch() 并不会立即返回，但是它仍然会在未来某一点上返回，当其他greenlet切换回来时。当这发生时，执行点恢复到 switch() 之后，而 switch() 返回刚才调用者发送来的对象。这意味着 x=g.switch(y) 会发送对象y到g，然后等着一个不知道是谁发来的对象，并在这里返回给x。

　　注意，任何尝试切换到死掉的greenlet的行为都会切换到死掉greenlet的父greenlet，或者父greenlet的父greenlet，等等。最终的父greenlet就是main greenlet，main greenlet永远不会死掉的。

Methods and attributes of greenlets
六、greenlet的方法和属性

g.switch(*args, **kwargs)

　　Switches execution to the greenlet g .

　　切换执行点到greenlet g。

g.run

　　The callable that g will run when it starts. After g started, this attribute no longer exists.

　　调用可执行的g，并启动。在g启动后，这个属性就不再存在了。

g.parent

　　The parent greenlet. This is writeable, but it is not allowed to create cycles of parents.

　　greenlet的父greenlet。这是可写的，但是不允许创建循环的父关系。

g.gr_frame

　　The current top frame, or None.

　　当前顶级帧，或者None。

g.dead

　　True if g is dead (i.e. it finished its execution).

　　判断greenlet是否已经死掉了。

bool(g)

　　True if g is active, False if it is dead or not yet started.

　　如果g是活跃的则返回True，在尚未启动或者结束后返回False。

g.throw([typ, [val, [tb]]])

　　Switches execution to the greenlet g, but immediately raises the given exception in g. If no argument is provided, the exception defaults to greenlet.GreenletExit . The normal exception propagation rules apply, as described above. Note that calling this method is almost equivalent to the following:

　　切换执行点到greenlet g ，但是立即在g中抛出指定的异常。如果没有提供参数，异常缺省就是 greenlet.GreenletExit 。异常传播规则如上文描述。注意调用这个方法等同于如下:

def raiser():
raise typ, val, tb
g_raiser = greenlet(raiser, parent=g)
g_raiser.switch()
　　except that this trick does not work for the greenlet.GreenletExit exception, which would not propagate from g_raiser to g .

　　注意这一招对于异常 greenlet.GreenletExit并不适用，因为这个异常不会从 g_raiser 传播到 g 。

greenlets and python

七、greenlets和Python线程

　　Greenlets can be combined with Python threads; in this case, each thread contains an independent “main” greenlet with a tree of sub-greenlets. It is not possible to mix or switch between greenlets belonging to different threads.

　　greenlets可以与Python线程一起使用；在这种情况下，每个线程包含一个独立的 main greenlet，并拥有自己的greenlet树。不同线程之间不可以互相切换greenlet。

Garbage-collecting live greenlets

八、垃圾收集活跃的greenlets

　　If all the references to a greenlet object go away (including the references from the parent attribute of other greenlets), then there is no way to ever switch back to this greenlet. In this case, a GreenletExit exception is generated into the greenlet. This is the only case where a greenlet receives the execution asynchronously. This gives try:finally: blocks a chance to clean up resources held by the greenlet. This feature also enables a programming style in which greenlets are infinite loops waiting for data and processing it. Such loops are automatically interrupted when the last reference to the greenlet goes away.

　　The greenlet is expected to either die or be resurrected by having a new reference to it stored somewhere; just catching and ignoring the GreenletExit is likely to lead to an infinite loop.

　　Greenlets do not participate in garbage collection; cycles involving data that is present in a greenlet’s frames will not be detected. Storing references to other greenlets cyclically may lead to leaks.

　　如果不再有对greenlet对象的引用时(包括其他greenlet的parent)，还是没有办法切换回greenlet。这种情况下会生成一个 GreenletExit 异常到greenlet。这是greenlet收到异步异常的唯一情况。应该给出一个 try .. finally 用于清理greenlet内的资源。这个功能同时允许greenlet中无限循环的编程风格。这样循环可以在最后一个引用消失时自动中断。

　　如果不希望greenlet死掉或者把引用放到别处，只需要捕捉和忽略 GreenletExit 异常即可。

　　greenlet不参与垃圾收集；greenlet帧的循环引用数据会被检测到。将引用传递到其他的循环greenlet会引起内存泄露。

Tracing support

九、追踪支持

　　Standard Python tracing and profiling doesn’t work as expected when used with greenlet since stack and frame switching happens on the same Python thread. It is difficult to detect greenlet switching reliably with conventional methods, so to improve support for debugging, tracing and profiling greenlet based code there are new functions in the greenlet module:

greenlet.gettrace()
　　Returns a previously set tracing function, or None.

greenlet.settrace(callback)

　　Sets a new tracing function and returns a previous tracing function, or None. The callback is called on various events and is expected to have the following signature:

复制代码
def callback(event, args):
if event == ‘switch‘:
origin, target = args
# Handle a switch from origin to target.
# Note that callback is running in the context of target
# greenlet and any exceptions will be passed as if
# target.throw() was used instead of a switch.
return
if event == ‘throw‘:
origin, target = args
# Handle a throw from origin to target.
# Note that callback is running in the context of target
# greenlet and any exceptions will replace the original, as
# if target.throw() was used with the replacing exception.
return
复制代码
　　For compatibility it is very important to unpack args tuple only when event is either ‘switch‘ or ‘throw‘ and not when event is potentially something else. This way API can be extended to new events similar to sys.settrace().

第一个例子

沿袭我们一直以来的习惯，先从例子开始，这次偷个懒，直接把官方文档中的例子拿过来：

from greenlet import greenlet

def test1():

print 12

gr2.switch()

print 34

def test2():

print 56

gr1.switch()

print 78

gr1 = greenlet(test1)

gr2 = greenlet(test2)

gr1.switch()

这里创建了两个greenlet协程对象，gr1和gr2，分别对应于函数test1()和test2()。使用greenlet对象的switch()方法，即可以切换协程。上例中，我们先调用”gr1.switch()”，函数test1()被执行，然后打印出”12″；接着由于”gr2.switch()”被调用，协程切换到函数test2()，打印出”56″；之后”gr1.switch()”又被调用，所以又切换到函数test1()。但注意，由于之前test1()已经执行到第5行，也就是”gr2.switch()”，所以切换回来后会继续往下执行，也就是打印”34″；现在函数test1()退出，同时程序退出。由于再没有”gr2.switch()”来切换至函数test2()，所以程序第11行”print 78″不会被执行。

所以，程序运行下来的输出就是：

12

56

34

很好理解吧。使用switch()方法切换协程，也比”yield”, “next/send”组合要直观的多。上例中，我们也可以看出，greenlet协程的运行，其本质是串行的，所以它不是真正意义上的并发，因此也无法发挥CPU多核的优势，不过，这个可以通过协程+进程组合的方式来解决，本文就不展开了。另外要注意的是，在没有进行显式切换时，部分代码是无法被执行到的，比如上例中的”print 78″。

父子关系

创建协程对象的方法其实有两个参数”greenlet(run=None, parent=None)”。参数”run”就是其要调用的方法，比如上例中的函数test1()和test2()；参数”parent”定义了该协程对象的父协程，也就是说，greenlet协程之间是可以有父子关系的。如果不设或设为空，则其父协程就是程序默认的”main”主协程。这个”main”协程不需要用户创建，它所对应的方法就是主程序，而所有用户创建的协程都是其子孙。大家可以把greenlet协程集看作一颗树，树的根节点就是”main”，上例中的”gr1″和”gr2″就是其两个字节点。

在子协程执行完毕后，会自动返回父协程。比如上例中test1()函数退出，代码会返回到主程序。让我们写个更清晰的例子来实验下：

from greenlet import greenlet

def test1():

print 12

gr2.switch()

print 34

def test2():

print 56

gr1 = greenlet(test1)

gr2 = greenlet(test2, gr1)

gr1.switch()

print 78

这里创建greenlet对象”gr2″时，指定了其父协程是”gr1″。所以在函数test2()里，虽然没有”gr1.switch()”代码，但是在其退出后，程序一样回到了函数test1()，并且执行”print 34″。同样，在test1()退出后，代码回到了主程序，并执行”print 78″。所以，最后的输出就是：

12

56

34

78

如果上例中，”gr2″的父协程不是”gr1″而是”main”的话，那test2()运行完毕就会回到主程序并直接打印”78″，这样”print 34″就不会执行。大家可以试一试。

还有一个重要的点，就是协程退出后，就无法再被执行了。如果上例在函数test1()中，再加一句”gr2.switch()”，运行的结果是一样的。因为第二次调用”gr2.switch()”，什么也不会运行。

def test1():

print 12

gr2.switch()

print 34

gr2.switch()

大家可能会感觉到父子协程之间的关系，就像函数调用一样，一个嵌套一个。的确，其实greenlet协程的实现就是使用了栈，其运行的上下文保存在栈中，”main”主协程处于栈底的位置，而当前运行中的协程就在栈顶。这同函数是一样。此外，在任何时候，你都可以使用”greenlet.getcurrent()”，获取当前运行中的协程对象。比如在函数test2()中执行”greenlet.getcurrent()”，其返回就等于”gr2″。

异常

既然协程是存放在栈中，那一个协程要抛出异常，就会先抛到其父协程中，如果所有父协程都不捕获此异常，程序才会退出。我们试下，把上面的例子中函数test2()的代码改为：

def test2():

print 56

raise NameError

程序执行后，我们可以看到Traceback信息：

File "parent.py", line 14, in

gr1.switch()

File "parent.py", line 5, in test1

gr2.switch()

File "parent.py", line 10, in test2

raise NameError

同时大家可以试下，如果将”gr2″的父协程设为空，Traceback信息就会变为：

File "parent.py", line 14, in

gr1.switch()

File "parent.py", line 10, in test2

raise NameError

因此，如果”gr2″的父协程是”gr1″的话，异常先回抛到函数test1()的代码”gr2.switch()”处。所以，我们再对函数test1()改动下：

def test1():

print 12

try:

    gr2.switch()

except NameError:

    print 90

print 34

运行后的结果，如果”gr2″的父协程是”gr1″，则异常被捕获，并打印90。否则，异常会被抛出。以上实验很好的证明了，子协程抛出的异常会根据栈里的顺序，依次抛到父协程里。

有一个异常是特例，不会被抛到父协程中，那就是”greenlet.GreenletExit”，这个异常会让当前协程强制退出。比如，我们将函数test2()改为：

def test2():

print 56

raise greenlet.GreenletExit

print 78

那代码行”print 78″永远不会被执行。但这个异常不会往上抛，所以其父协程还是可以正常运行。

另外，我们可以通过greenlet对象的”throw()”方法，手动往一个协程里抛个异常。比如，我们在test1()里调一个throw()方法：

def test1():

print 12

gr2.throw(NameError)

try:

    gr2.switch()

except NameError:

    print 90

print 34

这样，异常就会被抛出，运行后的Trackback是这样的：

File "exception.py", line 21, in

gr1.switch()

File "exception.py", line 5, in test1

gr2.throw(NameError)

如果将”gr2.throw(NameError)”放在”try”语句中，那该异常就会被捕获，并打印”90″。另外，当”gr2″的父协程不是”gr1″而是”main”时，异常会直接抛到主程序中，此时函数test1()中的”try”语句就不起作用了。

协程间传递消息

在介绍生成器时，我们聊过可以使用生成器的send()方法来传递参数。greenlet也同样支持，只要在其switch()方法调用时，传入参数即可。我们再来基于本文第一个例子改造下：

from greenlet import greenlet

def test1():

print 12

y = gr2.switch(56)

print y

def test2(x):

print x

gr1.switch(34)

print 78

gr1 = greenlet(test1)

gr2 = greenlet(test2)

gr1.switch()

在test1()中调用”gr2.switch()”，由于协程”gr2″之前未被启动，所以传入的参数”56″会被赋在test2()函数的参数”x”上；在test2()中调用”gr1.switch()”，由于协程”gr1″之前已执行到第5行”y = gr2.switch(56)”这里，所以传入的参数”34″会作为”gr2.switch(56)”的返回值，赋给变量”y”。这样，两个协程之间的互传消息就实现了。

让我们将上一篇介绍生成器时写的生产者消费者的例子，改为greenlet实现吧：

from greenlet import greenlet

def consumer():

last = ''

while True:

    receival = pro.switch(last)

    if receival is not None:

        print 'Consume %s' % receival

        last = receival

def producer(n):

con.switch()

x = 0

while x < n:

    x += 1

    print 'Produce %s' % x

    last = con.switch(x)

pro = greenlet(producer)

con = greenlet(consumer)

pro.switch(5)

先了解一下同步、异步、阻塞、非阻塞

同步和异步关注的是消息通信机制.

同步异步指的是调用者与被调用者两者之间的关系。

同步
所谓同步，就是在发出一个功能调用时，在没有得到结果之前，该调用就不会返回，一旦调用返回，就得到返回值了。换句话说,就是由调用者主动等待这个调用结果.按照此定义，其实绝大多数函数都是同步调用。但是一般而言，我们在说同步、异步的时候，特指那些需要其他程序或者IO协作或者需要一定时间完成的任务。

举例：
multiprocessing.Pool().apply#发起同步调用后，就在原地等着任务结束，根本不考虑任务是在计算还是在io阻塞，总之就是一股脑地等任务结束

简单一句话就是：调用者调用了一个功能时调用者要等着被调用者执行完毕，无论被调用者是在阻塞还是非阻塞状态,才能继续进行自己的任务

异步
异步的概念和同步相对。调用在发出之后,这个调用就直接返回了,所以没有返回结果.换句话说当一个异步功能调用发出后，调用者不能立刻得到结果。但是这个时候被调用者可以去执行下面的代码而不是一味的等待。

另外需要强调的一点：
当该异步功能完成后，被调用者可以通过状态、通知或回调来通知调用者。如果异步功能用状态来通知，那么调用者就需要每隔一定时间检查一次，效率就很低（有些初学多线程编程的人，总喜欢用一个循环去检查某个变量的值，这其实是一种很严重的错误）。如果是使用通知的方式，效率则很高，因为异步功能几乎不需要做额外的操作。至于回调函数，其实和通知没太多区别。

举例：
multiprocessing.Pool().apply_async() #发起异步调用后，并不会等待任务结束才返回，相反，会立即获取一个临时结果（并不是最终的结果，可能是封装好的一个对象）。

什么是Blocking?
阻塞调用是指调用结果返回之前，当前线程会被挂起（如遇到io操作）。调用线程只有在得到结果之后才会返回。函数只有在得到结果之后才会将阻塞的线程激活。

阻塞调用是指调用结果返回之前，当前线程会被挂起（如遇到io操作）。调用线程只有在得到结果之后才会返回。函数只有在得到结果之后才会将阻塞的线程激活。有人也许会把阻塞调用和同步调用等同起来，实际上他是不同的。对于同步调用来说，很多时候当前线程还是激活的，只是从逻辑上当前函数没有返回而已。

举例：

1. 同步调用：apply一个累计1亿次的任务，该调用会一直等待，直到任务返回结果为止，但并未阻塞住（即便是被抢走cpu的执行权限，那也是处于就绪态）;
2. 阻塞调用：当socket工作在阻塞模式的时候，如果没有数据的情况下调用recv函数，则当前线程就会被挂起，直到有数据为止。

非阻塞

非阻塞和阻塞的概念相对应，非阻塞调用指在不能立刻得到结果之前也会立刻返回，同时该函数不会阻塞当前线程。

告一段落

next!

使用yield实现协程操作例子
　

import time
import queue
def consumer(name):
    print("--->starting eating baozi...")
    while True:
        new_baozi = yield
        print("[%s] is eating baozi %s" % (name,new_baozi))
        #time.sleep(1)
 
def producer():
 
    r = con.__next__()
    r = con2.__next__()
    n = 0
    while n < 5:
        n +=1
        con.send(n)
        con2.send(n)
        print("33[32;1m[producer]33[0m is making baozi %s" %n )
 
 
if __name__ == '__main__':
    con = consumer("c1")
    con2 = consumer("c2")
    p = producer()

通常，我们写服务器处理模型的程序时，有以下几种模型：

（1）每收到一个请求，创建一个新的进程，来处理该请求；

（2）每收到一个请求，创建一个新的线程，来处理该请求；

（3）每收到一个请求，放入一个事件列表，让主进程通过非阻塞I/O方式来处理请求

上面的几种方式，各有千秋，

第（1）中方法，由于创建新的进程的开销比较大，所以，会导致服务器性能比较差,但实现比较简单。

第（2）种方式，由于要涉及到线程的同步，有可能会面临死锁等问题。

第（3）种方式，在写应用程序代码时，逻辑比前面两种都复杂。

综合考虑各方面因素，一般普遍认为第（3）种方式是大多数网络服务器采用的方式

看图说话讲事件驱动模型

在UI编程中，常常要对鼠标点击进行相应，首先如何获得鼠标点击呢？

方式一：创建一个线程，该线程一直循环检测是否有鼠标点击，那么这个方式有以下几个缺点：

1. CPU资源浪费，可能鼠标点击的频率非常小，但是扫描线程还是会一直循环检测，这会造成很多的CPU资源浪费；如果扫描鼠标点击的接口是阻塞的呢？
2. 如果是堵塞的，又会出现下面这样的问题，如果我们不但要扫描鼠标点击，还要扫描键盘是否按下，由于扫描鼠标时被堵塞了，那么可能永远不会去扫描键盘；
3. 如果一个循环需要扫描的设备非常多，这又会引来响应时间的问题；
   所以，该方式是非常不好的。

方式二：就是事件驱动模型
目前大部分的UI编程都是事件驱动模型，如很多UI平台都会提供onClick()事件，这个事件就代表鼠标按下事件。事件驱动模型大体思路如下：

1. 有一个事件（消息）队列；
2. 鼠标按下时，往这个队列中增加一个点击事件（消息）；
3. 有个循环，不断从队列取出事件，根据不同的事件，调用不同的函数，如onClick()、onKeyDown()等；
4. 事件（消息）一般都各自保存各自的处理函数指针，这样，每个消息都有独立的处理函数；
   

事件驱动编程是一种编程范式，这里程序的执行流由外部事件来决定。它的特点是包含一个事件循环，当外部事件发生时使用回调机制来触发相应的处理。另外两种常见的编程范式是（单线程）同步以及多线程编程。

让我们用例子来比较和对比一下单线程、多线程以及事件驱动编程模型。下图展示了随着时间的推移，这三种模式下程序所做的工作。这个程序有3个任务需要完成，每个任务都在等待I/O操作时阻塞自身。阻塞在I/O操作上所花费的时间已经用灰色框标示出来了。

在单线程同步模型中，任务按照顺序执行。如果某个任务因为I/O而阻塞，其他所有的任务都必须等待，直到它完成之后它们才能依次执行。这种明确的执行顺序和串行化处理的行为是很容易推断得出的。如果任务之间并没有互相依赖的关系，但仍然需要互相等待的话这就使得程序不必要的降低了运行速度。

在多线程版本中，这3个任务分别在独立的线程中执行。这些线程由操作系统来管理，在多处理器系统上可以并行处理，或者在单处理器系统上交错执行。这使得当某个线程阻塞在某个资源的同时其他线程得以继续执行。与完成类似功能的同步程序相比，这种方式更有效率，但程序员必须写代码来保护共享资源，防止其被多个线程同时访问。多线程程序更加难以推断，因为这类程序不得不通过线程同步机制如锁、可重入函数、线程局部存储或者其他机制来处理线程安全问题，如果实现不当就会导致出现微妙且令人痛不欲生的bug。

在事件驱动版本的程序中，3个任务交错执行，但仍然在一个单独的线程控制中。当处理I/O或者其他昂贵的操作时，注册一个回调到事件循环中，然后当I/O操作完成时继续执行。回调描述了该如何处理某个事件。事件循环轮询所有的事件，当事件到来时将它们分配给等待处理事件的回调函数。这种方式让程序尽可能的得以执行而不需要用到额外的线程。事件驱动型程序比多线程程序更容易推断出行为，因为程序员不需要关心线程安全问题。

当我们面对如下的环境时，事件驱动模型通常是一个好的选择：

1. 程序中有许多任务，而且…
2. 任务之间高度独立（因此它们不需要互相通信，或者等待彼此）而且…
3. 在等待事件到来时，某些任务会阻塞。

当应用程序需要在任务间共享可变的数据时，这也是一个不错的选择，因为这里不需要采用同步处理。

网络应用程序通常都有上述这些特点，这使得它们能够很好的契合事件驱动编程模型。

此处要提出一个问题，就是，上面的事件驱动模型中，只要一遇到IO就注册一个事件，然后主程序就可以继续干其它的事情了，只到io处理完毕后，继续恢复之前中断的任务，这本质上是怎么实现的呢？哈哈，下面我们就来一起揭开这神秘的面纱。。。。

SelectPollEpoll异步IO　IO多路复用

同步IO和异步IO，阻塞IO和非阻塞IO分别是什么，到底有什么区别？不同的人在不同的上下文下给出的答案是不同的。所以先限定一下本文的上下文。

本文讨论的背景是Linux环境下的network IO。
一 概念说明
在进行解释之前，首先要说明几个概念：

• 用户空间和内核空间
• 进程切换
• 进程的阻塞
• 文件描述符
• 缓存 I/O

用户空间与内核空间

现在操作系统都是采用虚拟存储器，那么对32位操作系统而言，它的寻址空间（虚拟存储空间）为4G（2的32次方）。操作系统的核心是内核，独立于普通的应用程序，可以访问受保护的内存空间，也有访问底层硬件设备的所有权限。

为了保证用户进程不能直接操作内核（kernel），保证内核的安全，操心系统将虚拟空间划分为两部分，一部分为内核空间，一部分为用户空间。针对linux操作系统而言，将最高的1G字节（从虚拟地址0xC0000000到0xFFFFFFFF），供内核使用，称为内核空间，而将较低的3G字节（从虚拟地址0x00000000到0xBFFFFFFF），供各个进程使用，称为用户空间。

进程切换
为了控制进程的执行，内核必须有能力挂起正在CPU上运行的进程，并恢复以前挂起的某个进程的执行。这种行为被称为进程切换。因此可以说，任何进程都是在操作系统内核的支持下运行的，是与内核紧密相关的。

从一个进程的运行转到另一个进程上运行，这个过程中经过下面这些变化：

1. 保存处理机上下文，包括程序计数器和其他寄存器。
2. 更新PCB信息。
3. 把进程的PCB移入相应的队列，如就绪、在某事件阻塞等队列。
4. 选择另一个进程执行，并更新其PCB。
5. 更新内存管理的数据结构。
6. 恢复处理机上下文。

总而言之就是很耗资源，具体的可以参考这篇文章：进程切换

注：进程控制块（Processing Control Block），是操作系统核心中一种数据结构，主要表示进程状态。其作用是使一个在多道程序环境下不能独立运行的程序（含数据），成为一个能独立运行的基本单位或与其它进程并发执行的进程。或者说，OS是根据PCB来对并发执行的进程进行控制和管理的。 PCB通常是系统内存占用区中的一个连续存区，它存放着操作系统用于描述进程情况及控制进程运行所需的全部信息

进程的阻塞
正在执行的进程，由于期待的某些事件未发生，如请求系统资源失败、等待某种操作的完成、新数据尚未到达或无新工作做等，则由系统自动执行阻塞原语(Block)，使自己由运行状态变为阻塞状态。可见，进程的阻塞是进程自身的一种主动行为，也因此只有处于运行态的进程（获得CPU），才可能将其转为阻塞状态。当进程进入阻塞状态，是不占用CPU资源的。

文件描述符fd
文件描述符（File descriptor）是计算机科学中的一个术语，是一个用于表述指向文件的引用的抽象化概念。

文件描述符在形式上是一个非负整数。实际上，它是一个索引值，指向内核为每一个进程所维护的该进程打开文件的记录表。当程序打开一个现有文件或者创建一个新文件时，内核向进程返回一个文件描述符。在程序设计中，一些涉及底层的程序编写往往会围绕着文件描述符展开。但是文件描述符这一概念往往只适用于UNIX、Linux这样的操作系统。

缓存 I/O
缓存 I/O 又被称作标准 I/O，大多数文件系统的默认 I/O 操作都是缓存 I/O。在 Linux 的缓存 I/O 机制中，操作系统会将 I/O 的数据缓存在文件系统的页缓存（ page cache ）中，也就是说，数据会先被拷贝到操作系统内核的缓冲区中，然后才会从操作系统内核的缓冲区拷贝到应用程序的地址空间。

缓存 I/O 的缺点：
数据在传输过程中需要在应用程序地址空间和内核进行多次数据拷贝操作，这些数据拷贝操作所带来的 CPU 以及内存开销是非常大的。

IO模式
刚才说了，对于一次IO访问（以read举例），数据会先被拷贝到操作系统内核的缓冲区中，然后才会从操作系统内核的缓冲区拷贝到应用程序的地址空间。所以说，当一个read操作发生时，它会经历两个阶段：

1. 等待数据准备 (Waiting for the data to be ready)
2. 将数据从内核拷贝到进程中 (Copying the data from the kernel to the process)

正式因为这两个阶段，linux系统产生了下面五种网络模式的方案。

• 阻塞 I/O（blocking IO）
• 非阻塞 I/O（nonblocking IO）
• I/O 多路复用（ IO multiplexing）
• 信号驱动 I/O（ signal driven IO）
• 异步 I/O（asynchronous IO）

注：由于signal drive IO在实际中并不常用，所以我这只提及剩下的四种IO Model。
阻塞 I/O（blocking IO）
在linux中，默认情况下所有的socket都是blocking，一个典型的读操作流程大概是这样：

当用户进程调用了recvfrom这个系统调用，kernel就开始了IO的第一个阶段：准备数据（对于网络IO来说，很多时候数据在一开始还没有到达。比如，还没有收到一个完整的UDP包。这个时候kernel就要等待足够的数据到来）。这个过程需要等待，也就是说数据被拷贝到操作系统内核的缓冲区中是需要一个过程的。而在用户进程这边，整个进程会被阻塞（当然，是进程自己选择的阻塞）。当kernel一直等到数据准备好了，它就会将数据从kernel中拷贝到用户内存，然后kernel返回结果，用户进程才解除block的状态，重新运行起来。

所以，blocking IO的特点就是在IO执行的两个阶段都被block了。

几乎所有的程序员第一次接触到的网络编程都是从listen()、send()、recv() 等接口开始的，使用这些接口可以很方便的构建服务器/客户机的模型。然而大部分的socket接口都是阻塞型的。ps：所谓阻塞型接口是指系统调用（一般是IO接口）不返回调用结果并让当前线程一直阻塞，只有当该系统调用获得结果或者超时出错时才返回。

实际上，除非特别指定，几乎所有的IO接口 ( 包括socket接口 ) 都是阻塞型的。这给网络编程带来了一个很大的问题，如在调用recv(1024)的同时，线程将被阻塞，在此期间，线程将无法执行任何运算或响应任何的网络请求。

一个简单的解决方案：

1. 在服务器端使用多线程（或多进程）。多线程（或多进程）的目的是让每个连接都拥有独立的线程（或进程），这样任何一个连接的阻塞都不会影响其他的连接。

该方案的问题是：

• 开启多进程或都线程的方式，在遇到要同时响应成百上千路的连接请求，则无论多线程还是多进程都会严重占据系统资源，降低系统对外界响应效率，而且线程与进程本身也更容易进入假死状态。
  改进方案：

• 很多程序员可能会考虑使用“线程池”或“连接池”。“线程池”旨在减少创建和销毁线程的频率，其维持一定合理数量的线程，并让空闲的线程重新承担新的执行任务。“连接池”维持连接的缓存池，尽量重用已有的连接、减少创建和关闭连接的频率。这两种技术都可以很好的降低系统开销，都被广泛应用很多大型系统，如websphere、tomcat和各种数据库等。

改进后方案其实也存在着问题：

• “线程池”和“连接池”技术也只是在一定程度上缓解了频繁调用IO接口带来的资源占用。而且，所谓“池”始终有其上限，当请求大大超过上限时，“池”构成的系统对外界的响应并不比没有池的时候效果好多少。所以使用“池”必须考虑其面临的响应规模，并根据响应规模调整“池”的大小。

对应上例中的所面临的可能同时出现的上千甚至上万次的客户端请求，“线程池”或“连接池”或许可以缓解部分压力，但是不能解决所有问题。总之，多线程模型可以方便高效的解决小规模的服务请求，但面对大规模的服务请求，多线程模型也会遇到瓶颈，可以用非阻塞接口来尝试解决这个问题。

非阻塞 I/O（nonblocking IO）
linux下，可以通过设置socket使其变为non-blocking。当对一个non-blocking socket执行读操作时，流程是这个样子：

当用户进程发出read操作时，如果kernel中的数据还没有准备好，那么它并不会block用户进程，而是立刻返回一个error。从用户进程角度讲 ，它发起一个read操作后，并不需要等待，而是马上就得到了一个结果。用户进程判断结果是一个error时，它就知道数据还没有准备好，于是它可以再次发送read操作。一旦kernel中的数据准备好了，并且又再次收到了用户进程的system call，那么它马上就将数据拷贝到了用户内存，然后返回。

所以，nonblocking IO的特点是用户进程需要不断的主动询问kernel数据好了没有。
I/O 多路复用（ IO multiplexing）
IO multiplexing就是我们说的select，poll，epoll，有些地方也称这种IO方式为event driven IO。select/epoll的好处就在于单个process就可以同时处理多个网络连接的IO。它的基本原理就是select，poll，epoll这个function会不断的轮询所负责的所有socket，当某个socket有数据到达了，就通知用户进程。

当用户进程调用了select，那么整个进程会被block，而同时，kernel会“监视”所有select负责的socket，当任何一个socket中的数据准备好了，select就会返回。这个时候用户进程再调用read操作，将数据从kernel拷贝到用户进程。

所以，I/O 多路复用的特点是通过一种机制一个进程能同时等待多个文件描述符，而这些文件描述符（套接字描述符）其中的任意一个进入读就绪状态，select()函数就可以返回。

这个图和blocking IO的图其实并没有太大的不同，事实上，还更差一些。因为这里需要使用两个system call (select 和 recvfrom)，而blocking IO只调用了一个system call (recvfrom)。但是，用select的优势在于它可以同时处理多个connection。

所以，如果处理的连接数不是很高的话，使用select/epoll的web server不一定比使用multi-threading + blocking IO的web server性能更好，可能延迟还更大。select/epoll的优势并不是对于单个连接能处理得更快，而是在于能处理更多的连接。）

在IO multiplexing Model中，实际中，对于每一个socket，一般都设置成为non-blocking，但是，如上图所示，整个用户的process其实是一直被block的。只不过process是被select这个函数block，而不是被socket IO给block。

异步 I/O（asynchronous IO）
Linux下的asynchronous IO其实用得很少。先看一下它的流程：

用户进程发起read操作之后，立刻就可以开始去做其它的事。而另一方面，从kernel的角度，当它受到一个asynchronous read之后，首先它会立刻返回，所以不会对用户进程产生任何block。然后，kernel会等待数据准备完成，然后将数据拷贝到用户内存，当这一切都完成之后，kernel会给用户进程发送一个signal，告诉它read操作完成了。

总结
blocking和non-blocking的区别
调用blocking IO会一直block住对应的进程直到操作完成，而non-blocking IO在kernel还准备数据的情况下会立刻返回。

synchronous IO和asynchronous IO的区别
在说明synchronous IO和asynchronous IO的区别之前，需要先给出两者的定义。POSIX的定义是这样子的：

• A synchronous I/O operation causes the requesting process to be blocked until that I/O operation completes;
• An asynchronous I/O operation does not cause the requesting process to be blocked;

两者的区别就在于synchronous IO做”IO operation”的时候会将process阻塞。按照这个定义，之前所述的blocking IO，non-blocking IO，IO multiplexing都属于synchronous IO。

有人会说，non-blocking IO并没有被block啊。这里有个非常“狡猾”的地方，定义中所指的”IO operation”是指真实的IO操作，就是例子中的recvfrom这个system call。non-blocking IO在执行recvfrom这个system call的时候，如果kernel的数据没有准备好，这时候不会block进程。但是，当kernel中数据准备好的时候，recvfrom会将数据从kernel拷贝到用户内存中，这个时候进程是被block了，在这段时间内，进程是被block的。

而asynchronous IO则不一样，当进程发起IO 操作之后，就直接返回再也不理睬了，直到kernel发送一个信号，告诉进程说IO完成。在这整个过程中，进程完全没有被block。

各个IO Model的比较如图所示：

通过上面的图片，可以发现non-blocking IO和asynchronous IO的区别还是很明显的。在non-blocking IO中，虽然进程大部分时间都不会被block，但是它仍然要求进程去主动的check，并且当数据准备完成以后，也需要进程主动的再次调用recvfrom来将数据拷贝到用户内存。而asynchronous IO则完全不同。它就像是用户进程将整个IO操作交给了他人（kernel）完成，然后他人做完后发信号通知。在此期间，用户进程不需要去检查IO操作的状态，也不需要主动的去拷贝数据。

三 I/O 多路复用之select、poll、epoll详解
select，poll，epoll都是IO多路复用的机制。I/O多路复用就是通过一种机制，一个进程可以监视多个描述符，一旦某个描述符就绪（一般是读就绪或者写就绪），能够通知程序进行相应的读写操作。但select，poll，epoll本质上都是同步I/O，因为他们都需要在读写事件就绪后自己负责进行读写，也就是说这个读写过程是阻塞的，而异步I/O则无需自己负责进行读写，异步I/O的实现会负责把数据从内核拷贝到用户空间。

select

select(rlist, wlist, xlist, timeout=None)
select 函数监视的文件描述符分3类，分别是writefds、readfds、和exceptfds。调用后select函数会阻塞，直到有描述副就绪（有数据 可读、可写、或者有except），或者超时（timeout指定等待时间，如果立即返回设为null即可），函数返回。当select函数返回后，可以 通过遍历fdset，来找到就绪的描述符。

select目前几乎在所有的平台上支持，其良好跨平台支持也是它的一个优点。select的一 个缺点在于单个进程能够监视的文件描述符的数量存在最大限制，在Linux上一般为1024，可以通过修改宏定义甚至重新编译内核的方式提升这一限制，但 是这样也会造成效率的降低。

poll

int poll (struct pollfd *fds, unsigned int nfds, int timeout);
不同与select使用三个位图来表示三个fdset的方式，poll使用一个 pollfd的指针实现。

struct pollfd {
int fd; /* file descriptor /
short events; / requested events to watch /
short revents; / returned events witnessed */
};
pollfd结构包含了要监视的event和发生的event，不再使用select“参数-值”传递的方式。同时，pollfd并没有最大数量限制（但是数量过大后性能也是会下降）。 和select函数一样，poll返回后，需要轮询pollfd来获取就绪的描述符。

从上面看，select和poll都需要在返回后，通过遍历文件描述符来获取已经就绪的socket。事实上，同时连接的大量客户端在一时刻可能只有很少的处于就绪状态，因此随着监视的描述符数量的增长，其效率也会线性下降。

　　

epoll
epoll是在2.6内核中提出的，是之前的select和poll的增强版本。相对于select和poll来说，epoll更加灵活，没有描述符限制。epoll使用一个文件描述符管理多个描述符，将用户关系的文件描述符的事件存放到内核的一个事件表中，这样在用户空间和内核空间的copy只需一次。

一 epoll操作过程

epoll操作过程需要三个接口，分别如下：

int epoll_create(int size)；//创建一个epoll的句柄，size用来告诉内核这个监听的数目一共有多大
int epoll_ctl(int epfd, int op, int fd, struct epoll_event event)；
int epoll_wait(int epfd, struct epoll_event events, int maxevents, int timeout);

1. int epoll_create(int size);
   创建一个epoll的句柄，size用来告诉内核这个监听的数目一共有多大，这个参数不同于select()中的第一个参数，给出最大监听的fd+1的值，参数size并不是限制了epoll所能监听的描述符最大个数，只是对内核初始分配内部数据结构的一个建议。
   当创建好epoll句柄后，它就会占用一个fd值，在linux下如果查看/proc/进程id/fd/，是能够看到这个fd的，所以在使用完epoll后，必须调用close()关闭，否则可能导致fd被耗尽。

2. int epoll_ctl(int epfd, int op, int fd, struct epoll_event *event)；
   函数是对指定描述符fd执行op操作。

• epfd：是epoll_create()的返回值。
• op：表示op操作，用三个宏来表示：添加EPOLL_CTL_ADD，删除EPOLL_CTL_DEL，修改EPOLL_CTL_MOD。分别添加、删除和修改对fd的监听事件。
• fd：是需要监听的fd（文件描述符）
• epoll_event：是告诉内核需要监听什么事

1. int epoll_wait(int epfd, struct epoll_event * events, int maxevents, int timeout);
   等待epfd上的io事件，最多返回maxevents个事件。
   参数events用来从内核得到事件的集合，maxevents告之内核这个events有多大，这个maxevents的值不能大于创建epoll_create()时的size，参数timeout是超时时间（毫秒，0会立即返回，-1将不确定，也有说法说是永久阻塞）。该函数返回需要处理的事件数目，如返回0表示已超时。