select，epoll，kqueue和evport之间的根本区别是什么?

本文介绍了select，epoll，kqueue和evport之间的根本区别是什么?的处理方法，对大家解决问题具有一定的参考价值，需要的朋友们下面随着小编来一起学习吧！

问题描述

我最近正在阅读Redis.Redis基于I/O复用实现了一个简单的事件驱动库.Redis表示将选择系统支持的最佳多路复用，并提供以下代码:

I am reading Redis recently.Redis implements a simple event-driven library based on I/O multiplexing.Redis says it would choose the best multiplexing supported by the system, and gives the following code:

/* Include the best multiplexing layer supported by this system.
 * The following should be ordered by performances, descending. */
#ifdef HAVE_EVPORT
#include "ae_evport.c"
#else
    #ifdef HAVE_EPOLL
    #include "ae_epoll.c"
    #else
        #ifdef HAVE_KQUEUE
        #include "ae_kqueue.c"
        #else
        #include "ae_select.c"
        #endif
    #endif
#endif

我想知道它们是否存在根本的性能差异?如果是这样，为什么?

I wanna know whether they have fundamental performance differences? If so, why?

最诚挚的问候

推荐答案

通常，所有异步I/O子系统都有不同的内部结构，但是在当前特定情况下，这些具体的异步I/O库用于支持尽可能多的平台.可能的.那就是:

In general, all Async I/O subsystems have different internals, but in current specific case these concrete async I/O libs are used to support as much platforms as possible. That is:

evport = Solaris 10
epoll = Linux
kqueue = OS X，FreeBSD
select =通常作为fallback

所有

evport = Solaris 10
epoll = Linux
kqueue = OS X, FreeBSD
select = usually installed on all platforms as a fallback

Evport，Epoll和KQueue具有 O(1)描述符选择算法复杂度，并且它们都使用内部内核空间内存结构.他们还可以提供很多(数十万个)文件描述符.

Evport, Epoll, and KQueue have O(1) descriptor selection algorithm complexity, and they all use internal kernel space memory structures. Also they can serve lots (hundreds of thousands) file descriptors.

除其他外，select最多只能提供 1024个描述符，并且对描述符进行完全扫描(因此每次迭代所有描述符以选择一个可使用的描述符)，因此复杂性是 O(n).

Apart the others, select can only serve up to 1024 descriptors, and does full scan of descriptors (so every time it iterates all descriptors to chose one to work with), so the complexity is O(n).

这篇关于select，epoll，kqueue和evport之间的根本区别是什么?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！

Platforms