使用recv，epoll和recv以及简单recv之间的性能明智区别是什么？ 我有4个组播流，我必须听，我想我有三个选择。我想哪个更好 n速度，系统调用，上下文切换。
1 poll with recv
2 epoll with recv
3 4 threads with recv
请建议我哪个更好，为什么
答案 0 :(得分：2)
您选择的三种解决方案中的哪一种无关紧要，差异不会很大。然而，有一个允许你保存系统调用（见最后）。
对于4个描述符，您可以假设poll几乎与epoll一样快。对于400或4,000个描述符，这会有很大的不同，但对于4个描述符，poll是绝对可以接受的（当然，你仍然可以使用epoll，但不要期待奇迹）。关于epoll的重要之处在于它如何根据它所观察的描述符的数量进行扩展，而不是监视它们的速度有多快。
轮询（使用任一功能）然后接收显然比直接在线程中接收更多的系统调用，尽管取决于问题的完全性质，这可能是一种太天真的看法在它。
如果可以独立处理来自这4个多播地址的数据报，您可以在每个端口启动一个进程并阻塞recv（最简单的解决方案！），但是否则您需要某种同步，这可能很棘手。如果你以前没有做过，那么可以（将）涉及额外的系统调用或旋转，并且很可能比多路复用接收慢。
无论你是否有线程，上下文切换的数量都将大致跟随系统调用的数量（因为你无论如何都会在系统调用中阻塞），除非你的机器非常忙，只有很少的备用内核。在这种情况下，将线程投入游戏将显着增加上下文切换次数。
组播假设UDP，这意味着＆＃34;完整的数据报＆＃34;。由于您考虑使用epoll，因此您认为可移植性不是问题。因此，您也可以使用另一个特定于Linux的系统调用：recvmmsg。这允许您只使用一个系统调用接收多个数据报。如果你只有一个套接字，你就会阻止它，因为它提供了一个＆＃34;接收 n ＆＃34;功能。但是，由于您仍需要复用4个套接字，因此首先使用epoll然后使用recvmmsg。