使用recv的轮询、使用recv和简单recv的epoll之间的性能差异是什么？我有4个多播流，我必须听我想我有三个选择。我想要哪个更好在速度、系统调用、上下文切换方面。
1 poll with recv
2 epoll with recv
3 4 threads with recv
请告诉我哪个更好，为什么
选择三种解决方案中的哪一种并不重要，差异也不会很大。但是，有一个可以让您保存系统调用（请参阅末尾）。
对于4个描述符，可以假设poll和epoll的速度几乎一样快。对于400或4000个描述符，情况会大不相同，但对于4个描述符，poll是绝对可以接受的（当然，尽管您仍然可以使用epoll，但不要指望会出现奇迹）。epoll的重要之处在于它如何根据它所监视的描述符的数量进行扩展，而不是它监视其中极少数描述符的速度有多快。
轮询（使用任一函数）然后接收显然比直接在线程中接收多了一个系统调用，尽管根据问题的确切性质，这可能是一种过于天真的看待方式。
如果来自这4个多播地址的数据报可以独立处理，那么你只需要在recv上为每个端口和块启动一个进程（最简单的解决方案！），但除此之外，你需要某种同步，如果你以前没有这样做，这可能很难做到，并且可能（将）涉及额外的系统调用或旋转，并且可能比多路复用接收慢。
上下文开关的数量将大致遵循系统调用的数量，无论您是否有线程（因为大多数时间都会阻塞系统调用），除非您有一台非常繁忙的机器，只有很少的空闲内核。在这种情况下，向游戏中抛出线程将显著增加上下文切换的数量。
多播假定UDP，意思是"完整的数据报"。由于您考虑使用epoll，因此您决定可移植性不是问题。因此，您还可以使用另一个特定于Linux的系统调用：recvmmsg。这允许您只通过一个系统调用接收多个数据报。如果你只有一个套接字，你就会阻止它，因为它提供了"最多接收n"的功能。但是，由于仍然需要多路复用4个套接字，因此将首先使用epoll，然后使用recvmmsg。