为什么我不应该使用异步（事件）IO
我现在正在写一些事件代码（在 python 中使用 gevent），我使用 nginx 作为 Web 服务器，我觉得两者都很棒。有人告诉我，事件之间存在权衡，但我无法看到它。有人可以解释一下吗？
詹姆斯
I am writing now writing some evented code (In python using gevent) and I use the nginx as a web server and I feel both are great. I was told that there is a trade off with events but was unable to see it. Can someone please shed some light?
James
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
事件编程的唯一困难是你永远不能阻塞。如果您使用一些在设计时考虑到线程的库，这可能很难实现。如果您不控制这些库，则可以选择 fork() + message ipc。
The only difficulty of evented programming is that you mustn't block, ever. This can be hard to achieve if you use some libraries that were designed with threads in mind. If you don't control these libraries, a fork() + message ipc is the way to go.
最大的问题是，如果没有线程，一个客户端的阻塞将导致所有客户端的阻塞。例如，如果一个客户端请求一种需要操作系统阻止请求进程的资源（磁盘上的文件、调出内存等），则所有客户端都将不得不等待。多线程服务器可以仅阻止一个客户端并继续为其他客户端提供服务。
也就是说，如果上述情况不太可能出现（即所有客户端都将请求相同的资源），那么事件驱动就是正确的选择。
Biggest issue is that without threads, a block for one client will cause a block for all client. For example, if one client requests a resource (file on disk, paged-out memory, etc) that requires the OS to block the requesting process, then all clients will have to wait. A multithreaded server can block just the one client and continue to serve others.
That said, if the above scenario is unlikely (that is, all clients will request the same resources), then event-driven is the way to go.