目錄還在持續學習中,本文是一個階段性的總結,
- 一、select
- 1.1 select函式
- 1.2 select流程
- 1.3 select問題
- 二、poll
- 三、epoll
- 3.1 epoll 函式
- 3.2 epoll 流程
一、select
select的核心是不停的遍歷檔案描述符,看看是否就緒,一般最多同時支持1024個檔案描述符,
1.1 select函式
int select(int nfds, fd_set *readfds, fd_set *writefds,fd_set *exceptfds, struct timeval *timeout);
- nfds:最大的檔案描述符加1
- readfds:監聽可讀集合
- writefds:監聽可寫集合
- exceptfds:監聽例外集合
- timeout:超時時間
1.2 select流程

喚醒 當前行程的程序通常是在所監測檔案的設備驅動內實作的,驅動程式維護了針對自身資源讀寫的等待佇列,當設備驅動發現自身資源變為可讀寫并且有行程睡眠在該資源的等待佇列上時,就會喚醒這個資源等待佇列上的行程,
1.3 select問題
- 每次呼叫時要重復地從用戶態讀入引數,
- 每次呼叫時要重復地掃描檔案描述符,遍歷所有檔案描述符,
- 每次在呼叫開始時,要把當前行程放入各個檔案描述符的等待佇列,在呼叫結束后,又把行程從各個等待佇列中洗掉,
- 對檔案描述符的數量有限制(一般為1024個)
select隨著檔案描述符數量的上升,性能會急劇下降
二、poll
poll的整體流程和select差不多,也是每次遍歷所有檔案描述符,性能不好,不過poll解決了select檔案描述符數量的限制問題,
三、epoll
select和poll運行效率的兩個瓶頸已經找出,現在的問題是怎么改進,
- 首先,如果要監聽1000個fd,每次poll都要把1000個fd 拷入內核,這是極大的浪費,內核干嘛不自己保存已經拷入的fd呢?**epoll就是自己保存拷入的fd **,它的API就已經說明了這一點,不是 epoll_wait的時候才傳入fd,而是通過epoll_ctl把所有fd傳入內核再一起"wait",這就省掉了不必要的重復拷貝,
- 其次,在 epoll_wait時,也不是把current輪流的加入fd對應的設備等待佇列,而是在設備等待佇列醒來時呼叫一個回呼函式(當然,這就需要“喚醒回呼”機制),把產生事件的fd歸入一個鏈表,然后回傳這個鏈表上的fd,
- 另外,epoll機制實作了自己特有的檔案系統eventpoll filesystem
3.1 epoll 函式
epoll總共提供了三個函式
-
int epoll_create(int size);
epoll_create是為了創建一個epoll檔案描述符,新創建的epoll檔案描述符帶有一個struct eventpoll結構,eventpoll結構如下,
struct eventpoll { spinlock_t lock; struct mutex mtx; wait_queue_head_t wq; /* Wait queue used by sys_epoll_wait() ,呼叫epoll_wait()時, 我們就是"睡"在了這個等待佇列上*/ wait_queue_head_t poll_wait; /* Wait queue used by file->poll() , 這個用于epollfd本事被poll的時候*/ struct list_head rdllist; /* List of ready file descriptors, 所有已經ready的epitem都在這個鏈表里面*/ struct rb_root rbr; /* RB tree root used to store monitored fd structs, 所有要監聽的epitem都在這里*/ epitem *ovflist; /*存放的epitem都是我們在傳遞資料給用戶空間時監聽到了事件*/. struct user_struct *user; /*這里保存了一些用戶變數,比如fd監聽數量的最大值等*/ };這個結構上再掛一個紅黑樹,而這個紅黑樹就是每次epoll_ctl時fd存放的地方,
-
int epoll_ctl(int epfd, int op, int fd, struct epoll_event *event);
此函式是添加、洗掉、修改事件
-
int epoll_wait(int epfd, struct epoll_event *events, int maxevents, int timeout);
此函式是等待條件滿足,回傳值為準備就緒的事件數
3.2 epoll 流程

【參考】
1.https://www.cnblogs.com/Anker/p/3265058.html
2.https://blog.csdn.net/weixin_42462202/article/details/95315926
3.https://blog.csdn.net/turkeyzhou/article/details/8609360
4.http://blog.chinaunix.net/uid-20643761-id-1594860.html
5.http://blog.chinaunix.net/uid-28541347-id-4236779.html
6.http://blog.chinaunix.net/uid-28541347-id-4238524.html
轉載請註明出處,本文鏈接:https://www.uj5u.com/qita/230198.html
標籤:其他
上一篇:高危:弱密碼問題
