除了select与epoll之外，poll也能够同时等待多个fd。它在Linux内核源码中的什么地方实现？它和select更相似还是和epoll更相似？为什么？

poll 在 Linux 内核源码中的实现在 `fs/select.c` 文件中。它和 select 更相似，因为它们都使用了传统的文件描述符集合来管理需要监听的文件描述符。但是它们之间的主要区别在于，poll 没有使用 select 中存在的文件描述符集合的限制，它使用一个可变长度的数组来存储需要监听的文件描述符。

相比之下，epoll 更加高效，因为它使用了内核事件表来管理需要监听的文件描述符，避免了每次调用时都需要将文件描述符集合从用户空间拷贝到内核空间的开销。此外，epoll 还支持边缘触发（Edge Triggered，ET）和水平触发（Level Triggered，LT）两种模式，更加灵活。

因此，虽然 poll 和 select 在某些场景下仍然有其优势，但是在大多数情况下，epoll 是更好的选择。

相关问题

select、epoll和poll的区别?

select、poll、epoll 都是 I/O 多路复用的机制，可以通过在一个线程中监视多个文件描述符（包括 socket）的可读可写等事件，从而减少阻塞，提升 I/O 性能。

其中 select 是最古老的机制，它将待监视的文件描述符集合复制到内核中，内核遍历每个文件描述符，检查其是否有事件发生，判断完成后将事件发生的文件描述符集合返回给用户空间。select 的缺点是每次操作都需要重新构造待监视集合，效率较低。同时，select 对于每个监视对象数量有限制。

poll 与 select 的作用相同，但是其采用的是链表结构，因此相对于 select 而言更加节省空间，同时监视对象数量的上限也更高。poll 的缺点是，与 select 一样，每次操作都需要把监视对象集合从用户空间复制到内核中。

epoll 是 Linux 特有的机制，其使用了一个 epoll 文件描述符来管理所有待监视的文件描述符，可以只在 epoll 实例上注册一次，从而避免了那些需要重复复制大量文件描述符的缺点。另外，epoll 对于大量连接时的性能表现也更优秀。

总的来说，select 和 poll 适用于比较简单的场景，而对于高性能、大规模连接和大量数据的场景，epoll 更为适用。

select poll epoll 内核

选择poll、epoll是在Linux内核中进行事件驱动编程时常用的机制。

poll是一种传统的I/O多路复用机制，它通过一个数组来管理需要监听的文件描述符，当有事件发生时，可以通过遍历数组来找到对应的文件描述符并进行处理。poll的缺点是效率较低，当文件描述符数量较大时，遍历整个数组的开销较大。

epoll则是在Linux 2.6内核中引入的新机制，它通过使用红黑树和双向链表的数据结构，将需要监听的文件描述符添加到epoll实例中，并通过epoll_wait函数等待事件的发生。相比于poll，epoll在处理大量文件描述符时具有更高的效率，因为它采用了事件通知的方式，只有真正有事件发生的文件描述符才会被通知。

对于选择poll还是epoll，需要根据具体的场景和需求来进行选择。如果文件描述符数量较少并且程序简单，可以选择poll；如果文件描述符数量较大或者需要高性能的实时处理，可以选择epoll。