select与epoll

三世轮回 提交于 2020-02-25 04:24:28

select

 
监听一组句柄fd_set,第一次调用的时候循环所有句柄对应的驱动函数xx_poll,socket的话就是sock_poll。
循环遍历完毕之后会如果发现有可用的(活跃状态的)fd,则返回,返回的时候会返回活跃的fd个数,同时会
把不活跃的fd在fd_set移除。如果循环fd_set一遍以后发现没有活跃的fd。假设此时socket在非阻塞模式下,
那么select会重复遍历这些fd_set直到超过了我们设置的时间限制,可是在阻塞模式下呢,怎么处理?
阻塞模式下我们没有必要设置超时限制,因为如果第一遍变量fd_set发现没有活跃的fd那么,这条进程会被
挂起的。进程怎么被激活呢,实际上进程是被挂在了n个fd的等待队列里,只要一个fd准备就绪那么进程就
会被唤醒,网卡接收了数据包发送一个中断给内核,内核处理这个中断,唤醒进程,这里是涉及到软中断的
,有兴趣可以看看。select被唤醒之后,并不知道是哪一个fd把自己唤醒的,所以还要来一个遍历,过程跟
上面说的是一样的。select阻塞到返回经历的内核和用户空间的拷贝,先把fd_set从用户空间拷贝给内核空
间,内核空间处理完毕之后把活动的fd再copy回来。其实后者还好,但是前者当fd_set百万级别的时候,就
费劲了。个中细节我并非完全了解,可是单看这个设计模式就觉着有效率问题了,感觉真的很傻,copy不说,
这个遍历所有描述符实在是太费劲了,而且每次在调用开始时,要把当前进程放入各个文件描述符的等待队列
在调用结束后,又把进程从各个等待队列中删除。
 
 
epoll
 
epoll的实现说白了,就是新发明了一个迷你文件系统:eventpollfs。其实,这需要sock_poll驱动的辅助
才能完成这样的设计,话说如果关注到epoll和select了,还不了解一下驱动的话,是看不动的。epoll的一
组函数:epoll_create,epoll_ctl,epoll_wait,就这三个函数完成百万并发醉了么?简单的可以这么理解,
epoll_create : 创建红黑树和就绪列表,实际他创建了一个专属于epoll文件系统的一个文件
epoll_ctl      :向红黑树添加socket句柄,向内核注册回调函数,用于当中断事件来临时,向准备就绪列表插
                  入数据
epoll_wait    :返回准备就绪列表的数据
 
准备就绪列表怎么维护的呢?当我们在做epoll_ctl时会给内核中断处理程序注册一个函数,告诉内核,如果这个句柄的中断到了,就把他放在准备就绪list链表里。
 
另外还有就是epoll的水平触发和边缘触发
 
水平触发level-triggered lT 只要满足条件就触发一个事件,只要数据没有被获取,内核会不断通知你
边缘出发edge-triggered ET 每当状态变化,触发一个事件。
具体例子吧,假设一个socket本来无数据可读,现在来了100个字节,这时候状态发生了变化,那么水平触发
和边缘出发都会被激活,可是呢,我们这次只读了20个字节,对于水平触发来说,还有80字节没读呢,再去监
听端口还是应该被触发可读调用,但是对于边缘触发的设计模式来说,因为刚才状态是从不可读变为可读,而现在是可读维持为可读,状态没变化,所以现在没必要再触发可读调用了。
这只是种设计思想而已,比如epoll,在就绪列表做点名堂就可以了,比如一个socket,假设没有被读完,提供是否再次放回到就绪列表中这两个选项,就成了两种触发了。
易学教程内所有资源均来自网络或用户发布的内容,如有违反法律规定的内容欢迎反馈
该文章没有解决你所遇到的问题?点击提问,说说你的问题,让更多的人一起探讨吧!