事件驱动IO和阻塞vs NonBlocking

Question

谁能给我解释一下事件驱动的IO系统调用，比如select、poll和epoll，与阻塞IO和非阻塞IO有什么关系？

我不明白这些概念有什么关联--如果有关联的话

Answer 1

select系统调用几乎在所有Unixes中都受支持，并为用户应用程序提供了监视一组描述符并获取该组中哪个子集已准备好读/写的信息的方法。它的特殊接口有点笨拙，在大多数内核中的实现充其量也是平庸的。

epoll只在Linux中提供用于相同的目的，但在效率和编程接口方面比select有了巨大的改进。其他的联盟也有他们的特殊呼叫。

也就是说，事件驱动IO系统调用既不需要阻塞描述符，也不需要非阻塞描述符。阻塞是一种会影响read、write、accept和connect等系统调用的行为。select和epoll_wait确实有阻塞超时，但这与描述符无关。

当然，将这些事件驱动的系统调用与阻塞描述符一起使用有点奇怪，因为您希望在收到数据可用的通知后，可以立即读取数据而不会阻塞。总是依赖于阻塞描述符在通知您它的准备就绪之后不会阻塞，这有点冒险，因为竞争条件是可能的。

非阻塞的、事件驱动的IO可以大大提高服务器应用程序的效率，因为每个描述符(连接)都不需要线程。将Apache web服务器与Nginx或Lighttpd在性能方面进行比较，您将看到其中的好处。

Answer 2

它们在很大程度上是无关的，除非出于以下原因，您可能希望将非阻塞文件描述符与事件驱动IO一起使用：

1. 的老版本在内核中肯定有错误，即使在select指示套接字是可读的(这发生在UDP套接字和具有错误校验和的数据包中)之后，read也会阻塞。当前版本的Linux可能仍然有一些这样的bug；我不确定。
2. 如果有任何其他进程可以访问您的文件描述符并对其进行读/写的可能性，或者如果您的程序是多线程的并且其他线程可能会这样做，那么在select确定文件描述符是可读/可写的和您的程序在其上执行IO之间存在竞争条件，这可能会导致阻塞。
3. 您几乎肯定希望在调用connect之前使套接字是非阻塞的；否则，您将阻塞，直到建立连接为止。使用select确定连接成功的时间，使用select确定连接是否失败。

Answer 3

select和类似的函数(您前面提到过几个)通常用于在事件驱动系统中实现事件循环。

也就是说，应用程序不是直接从套接字或文件执行read()，而是在多个文件描述符上调用select()，等待其中任何一个文件描述符上的数据可用。

当文件描述符可用时，可以确保数据可用，并且read()操作不会阻塞。

这是同时处理来自多个源的数据的一种方式，而无需求助于多个线程。