以下单线程UDP客户端应用程序是否会在使用epoll而不是在非阻塞套接字上调用recvfrom / sendto时看到性能优势？
让我解释一下客户。
我正在编写基于单线程UDP的客户端（自定义协议），它使用非阻塞I / O发送和接收数据，我的同事建议我使用epoll。 客户端发送和接收多个信息包，这些信息包都与唯一的会话ID相关联，并且可以同时运行多个会话。
如果我使用epoll，那么epoll_wait可能会等待10-20个文件描述符的数量有限。每个文件描述符将与一个会话相关联。所以最多10到20个会话，这个数字将被强制执行。
每个会话都有自己的状态机。从单个线程我需要合理地频繁运行每个状态机并轮询相关的套接字。
在我的情况下，我必须使用epoll_wait，超时为零或一些非常小的值，这样我就可以给每个会话运行状态机的CPU时间。 如果有会话数据，则需要将其定向到关联的状态机。
但是，我用这么少的文件描述符看不出这个设计的好处。
我看到它的方式是我有两个设计选项： 1.在使用epoll的主循环中，我可以使用epoll_wait轮询描述符，使用小超时或无超时。
此时如何处理数据是我陷入困境的地方......要么我立即将其读取然后将其放入队列中以便每个状态机在运行时接收，或者我设置了状态机上的标志告诉它数据正在等待，当状态机运行时它将通过调用recvfrom来获取数据。或者，我读取数据并立即处理它并运行状态机。
或... 2，只需从主循环运行每个状态机并调用recvfrom。如果我得到一些数据，请处理它。如果我不这样做那么状态机需要做的其他事情。当没有数据时，是否存在巨大的开销调用？
随着epoll路线的进行，我正在编写一些额外的复杂性。如果在我的情况下有更强的可能性，那么我将开始这样做。但是，如果第二种方式非常简单，那么我就不会使用epoll。
有什么想法吗？
答案 0 :(得分：2)
不，实际上使用epoll使用poll的情况会更糟，如果从集合中添加和删除文件描述符是一个非常罕见的事件。使用epoll，单个系统调用执行整个操作。使用epoll，您需要多个系统调用来修改集合，然后等待它。
除非您正在编写一个旨在扩展到数十，数百或数千个长期持久连接的服务器，否则{{1}}不仅是过早优化，而且实际上是一种悲观。它也完全不标准且不便携。