协程和 epoll 这种事件驱动对比，有什么优缺点

[thomaswang]

比如回射程序(客户端连接服务端，发送数据，服务端接受数据，返回给客户端)

服务端用协程和单进程 epoll 事件驱动模型对比，各有什么优势

疑惑 1 协程如果遇到未准备好的 io 会 yield, 谁来发现这个事件到来了呢，这个不像 epoll 可以返回可读可写的描述符，怎么 resume 这个协程，让它继续执行呢

疑惑 2 协程不能利用多核，单进程 epoll 也不能利用多核啊，是这样吗

[chenqh]

python tornado 的协程就是用 epoll 来搞的，

[lianghh]

epoll 只是操作系统底层提供的一种多路复用机制，而协程则是更高一层的抽象。因为抽象出了协程这个概念，这样应用层的程序员就无须关心下层如何调度和实现的了，更具通用性。例如 goroutine 就可以使用到多核，你所谓的“协程不能利用多核”是指你所在的平台实现限制导致他不能使用多核，协程本身没有限制。协程 和 epoll 这两者不等同不能去比较，真正应该比较的我觉得是线程和协程。线程由系统调度导致多次陷入内核态，而协程由语言或者框架调度，很多切换都是在用户态完成，性能更加，这也是语言或者框架本身抽象协程的目的。

[cheesea]

协程可以通过 epoll 来切换呀。
epoll 只是当有事件发生时通知你，至于对事件的处理，你可以单进程也可以交给线程或者协程去做，这个不一定要单进程的。这篇文章可以参考下 http://aosabook.org/en/500L/a-web-crawler-with-asyncio-coroutines.html，写的挺好。

[eslizn]

1.并不是谁来发现这个事件到来，而是由其他协程 yield 时来重试
2.是，不过可用通过配合多进程／多线程来解决这个问题，一个进程／线程来接收和响应请求，其他的分配给处理逻辑

[Gathaly]

好像不是同一个东西，一个是 IO 模型，一个是类似线程间的调度吧

[thomaswang]

@chenqh 就拿 tornado(这个我不熟)来说，如果是 epoll 管理所有的描述符，有事件到来时 resume 指定的协程，我觉得这个效率不如
@eslizn 所说的，epoll+开多进程 /线程处理逻辑，这种即解决了并发，也利用了多核，但是这样可能会过多的切换，还有就是要考虑抢占来的同步和互斥问题, 所以这个协程到底怎么用的呢

[eslizn]

@thomaswang 协程本质上并是串行的，所以在协程中是“线程安全”的。我猜测你说的是指跨线程、进程的资源共享、竞争场景，那么可以配合共享内存等方式来解决