对于select和poll，其主要原理跟epoll不同
poll和select的共同点就是，对全部指定设备（fd）都做一次poll，当然这往往都是还没有就绪的，那就会通过回调函数把当前进程注册到设备的等待队列，如果所有设备返回的掩码都没有显示任何的事件触发，就去回调函数的函数指针，进入有限时的睡眠状态，再恢复和不断做poll，再作有限时的睡眠，直到其中一个设备有事件触发为止。
总结：首先遍历所有监控的FD，对每个fd进行poll操作，所谓的poll操作包括把当前current进程挂到fd的等待队列上（如果在之后的睡眠时间内，此fd就绪的话，会唤醒睡眠的进程（这是通过回调函数实现的？？）），设置mask。如第一次对所有fd进行poll操作之后，没有任何fd就绪的，则进程进去schedule_timeout，即睡眠，如果睡眠时钟到，再次唤醒进程，重新对所有的FD，进行poll操作。
在设备收到一条消息（网络设备）或填写完文件数据（磁盘设备）后，会唤醒设备等待队列上睡眠的进程，这时current便被唤醒了。
__pollwait()函数中填充poll_table_entry结构体时注册的唤醒回调函数pollwake()，
进程被唤醒的条件有2：一是上面说的“一定时间”到了，二是被驱动程序唤醒。驱动程序发现条件就绪时，就把“某个队列”上挂着的进程唤醒，这个队列，就是前面通过poll_wait把本进程挂过去的队列。
总结：select和poll的缺点
1.每次要调用select和poll，意味着每次调用都要将fd列表从用户态拷贝到内核态，当fd数目很多时，这会造成低效。
2.每次做一次这样的系统调用都得轮询所有FD，次数是设备数*（睡眠次数-1），也就是时间复杂度是O（n），还得做几次O（n）呢。可见，对于现在普遍的服务器程序，需要同时并发监听数千个连接，并且连接需要重复使用的情况，poll和select就存在这样的性能瓶颈。
3、调用结束之后，需要遍历所有的FD，才能得到结果，即是select返回的是含有整个句柄的数组，应用程序需要遍历整个数组才能发现哪些句柄发生了事件，而epoll返回的是仅仅是就绪的数组