• client程序要同一时候处理多个socket。
• client程序要同一时候处理用户输入和网络连接。
• TCPserver同一时候处理监听socket和连接socket。
• server要同一时候处理TCP请求和UDP请求。

#include <sys/select.h> 
#include <sys/time.h> 
int select(int maxfd, fd_set *readfds, fd_set *writefds, fe_set *exceptfds, const struct timeval *timeout); 

select调用返回时。内核将改动它们来通知应用程序哪些文件描写叙述符已经就绪。

这3个參数是fd_set结构体指针类型。
因为位操作过于繁琐。我们应该使用以下的一系列宏来訪问fd_set结构体中的位：

void FD_CLR(int fd, fd_set *fdset)     /* 清除fdse全部位.*/
int FD_ISSET(int fd, fd_set *fdset)    /* 測试fdset的位fd是否被设置 */
void FD_SET(int fd, fd_set *fdset)     /* 设置fdset的位fd */
void FD_ZERO(fd_set *fdset)            /* 清除fdset的位fd */

它是一个timeval结构类型的指针，採用指针參数是由于内核将改动它以告诉程序select等待了多久。只是我们不能全然信任select调用返回后的timeout值，比方调用失败时timeout值是不确定的。timeout结构体的定义例如以下：

struct timeval {
       long tv_sec; // seconds
       long tv_usec; // and microseconds
};

文件描写叙述符就绪条件

poll系统调用

#include <poll.h>
int   poll(struct pollfd *fd, nfds_t nfds, int timeout);

struct pollfd {
       int fd;        /* 文件描写叙述符 */
       short events; /* 等待的事件 */
       short revents; /* 实际发生了的事件 */
};

　　POLLPRI　　　　　　　　 有紧迫数据可读。
　　POLLOUT　　　　　　      写数据不会导致堵塞。
　　POLLWRNORM　　　　　  写普通数据不会导致堵塞。

　　POLLWRBAND　　　　　   写优先数据不会导致堵塞。
　　POLLMSGSIGPOLL 　　　　消息可用。
　　此外，revents域中还可能返回下列事件：
　　POLLER　　   指定的文件描写叙述符错误发生。
　　POLLHUP　　 指定的文件描写叙述符挂起事件。

　　POLLNVAL　　指定的文件描写叙述符非法。
这些事件在events域中无意义，由于它们在合适的时候总是会从revents中返回。

typedef unsigned long int nfds_t;

epoll系列系统调用

内核事件表

#include<sys/epoll.h>
int epoll_create(int size);

#include <sys/epoll.h>
int epoll_ctl(int epfd, int op, int fd, struct epoll_event *event)

struct epoll_event {
       __uint32_t events; /* Epoll events */
       epoll_data_t data; /* User data variable */
};

epoll_wait函数

#include <sys/epoll.h>
int epoll_wait(int epfd,struct epoll_event * events,int maxevents,int timeout);

LT和ET模式

EPOLLONESHOT事件

于是就出现了两个线程同一时候操作一个socket的局面。

这当然不是我们期望的。

我们期望的是一个socket连接在随意时刻都仅仅能被一个线程处理。这一点能够使用epoll的EPOLLONESHOT事件来实现。

epoll的长处

对于那些须要支持上万连接数目的IMserver来说显然太少了。这时候你一是能够选择改动这个宏然后又一次编译内核，只是资料也同一时候指出这样 会带来网络效率的下降；二是能够选择多进程的解决方式(传统的Apache方案)。只是尽管linux上面创建进程的代价比較小，但仍旧是不可忽视的，加 上进程间数据同步远比不上线程间同步高效。所以这也不是一种完美的方案。

只是epoll 没有这个限制。它所支持的FD上限是最大能够打开文件的数目，这个数字一般远大于select 所支持的2048。举个样例，在1GB内存的机器上大约是10万左右。详细数目能够cat /proc/sys/fs/file-max察看，一般来说这个数目和系统内存关系非常大。
2）IO效率不随FD数目添加而线性下降
    传统select/poll的还有一个致命弱点就是当你拥有一个非常大的socket集合，由于网络得延时，使得任一时间仅仅有部分的socket是"活跃" 的，而select/poll每次调用都会线性扫描所有的集合。导致效率呈现线性下降。可是epoll不存在这个问题，它仅仅会对"活跃"的socket进 行操作---这是由于在内核实现中epoll是依据每一个fd上面的callback函数实现的。于是，仅仅有"活跃"的socket才会主动去调用 callback函数，其它idle状态的socket则不会，在这点上，epoll实现了一个"伪"AIO，由于这时候推动力在os内核。

在一些 benchmark中，假设全部的socket基本上都是活跃的---比方一个快速LAN环境，epoll也不比select/poll低多少效率，但若 过多使用的调用epoll_ctl，效率略微有些下降。然而一旦使用idle connections模拟WAN环境。那么epoll的效率就远在select/poll之上了。
3） 使用mmap加速内核与用户空间的消息传递
    这点实际上涉及到epoll的详细实现。不管是select,poll还是epoll都须要内核把FD消息通知给用户空间，怎样避免不必要的内存拷贝就显 得非常重要，在这点上，epoll是通过内核于用户空间mmap同一块内存实现的。而假设你像我一样从2.5内核就開始关注epoll的话。一定不会忘记手 工mmap这一步的。
4） 内核微调
    这一点事实上不算epoll的长处。而是整个linux平台的长处。

或许你能够怀疑linux平台，可是你无法回避linux平台赋予你微调内核的能力。比 如。内核TCP/IP协议栈使用内存池管理sk_buff结构，能够在执行期间动态地调整这个内存pool(skb_head_pool)的大小---通 过echo XXXX>/proc/sys/net/core/hot_list_length来完毕。

再比方listen函数的第2个參数(TCP完毕3次握 手的数据包队列长度)，也能够依据你平台内存大小来动态调整。甚至能够在一个数据包面数目巨大但同一时候每一个数据包本身大小却非常小的特殊系统上尝试最新的 NAPI网卡驱动架构。