筆者一直覺得如果能知道從應用到框架再到操作系統的每一處代碼,是一件Exciting的事情。
大部分高性能網絡框架采用的是非阻塞模式。筆者這次就從linux源碼的角度來闡述socket阻塞(block)和非阻塞(non_block)的區別。 本文源碼均來自采用Linux-2.6.24內核版本。
TCP 非阻塞 client 端的例子
如果我們要產生一個非阻塞的socket,在C語言中如下代碼所示:
由于網絡協議非常復雜,內核里面用到了大量的面向對象的技巧,所以我們從創建連接開始,一步一步追述到最后代碼的調用點。
socket 的創建
很明顯,內核的第一步應該是通過AF_INET、SOCK_STREAM以及最后一個參數0定位到需要創建一個TCP的socket,如下圖綠線所示:
我們跟蹤源碼調用
進一步分析__sock_create的代碼判斷:
由于family是AF_INET協議,注意在操作系統里面定義了PF_INET等于AF_INET, 內核通過函數指針實現了對pf(net_proto_family)的重載。如下圖所示:
則通過源碼可知,由于是AF_INET(PF_INET),所以net_families[PF_INET].create=inet_create(以后我們都用PF_INET表示),即
pf->create = inet_create; 進一步追溯調用:
上面的代碼就是在INET中尋找SOCK_STREAM的過程了 我們再看一下inetsw[SOCK_STREAM]的具體配置:
這邊也用了重載,AF_INET有TCP、UDP以及Raw三種:
從上述代碼,我們可以清楚的發現sock->ops=&inet_stream_ops;
即sock->ops->recvmsg = sock_common_recvmsg;
同時sock->sk->sk_prot = tcp_prot;
我們再看下tcp_prot中的各個函數重載的定義:
fcntl控制socket的阻塞非阻塞狀態
我們用fcntl修改socket的阻塞非阻塞狀態。 事實上: fcntl的作用就是將O_NONBLOCK標志位存儲在sock_fd對應的filp結構的f_lags里,如下圖所示。
追蹤setfl代碼:
上圖中,由sock_fd在task_struct(進程結構體)->files_struct->fd_array中找到對應的socket的file描述符,再修改file->flags
在調用socket.recv的時候
我們跟蹤源碼調用:
由上文可知: sock->ops->recvmsg = sock_common_recvmsg;
- sock
值得注意的是,在sock_recmsg中,有對標識O_NONBLOCK的處理
上述代碼中sock關聯的file中獲取其f_flags,如果flags有O_NONBLOCK標識,那么就設置msg_flags為MSG_DONTWAIT(不等待)。
fcntl與socket就是通過其共同操作File結構關聯起來的。
- 繼續跟蹤調用
sock_common_recvmsg
由上文可知: sk->sk_prot->recvmsg 其中sk_prot=tcp_prot,即最終調用的是tcp_prot->tcp_recvmsg,上面的代碼可以看出,如果fcntl(O_NONBLOCK)=>MSG_DONTWAIT置位=>(flags & MSG_DONTWAIT)>0, 再結合tcp_recvmsg的函數簽名,即如果設置了O_NONBLOCK的話,設置給tcp_recvmsg的nonblock參數>0,關系如下圖所示:
- 最終的調用邏輯tcp_recvmsg
首先我們看下tcp_recvmsg的函數簽名:
顯然我們關注焦點在(int nonblock這個參數上):
上面的邏輯歸結起來就是:
(1)在設置了nonblock的時候,如果copied>0,則返回讀了多少字節,如果copied=0,則返回-EAGAIN,提示應用重復調用。
(2)如果沒有設置nonblock,如果讀取的數據>=期望,則返回讀取了多少字節。如果沒有則用sk_wait_data將當前進程等待。
如下流程圖所示:
- 阻塞函數sk_wait_data
sk_wait_data代碼-函數為:
該函數調用schedule_timeout進入睡眠,其進一步調用了schedule函數,首先從運行隊列刪除,其次加入到等待隊列,最后調用和體系結構相關的switch_to宏來完成進程間的切換。
如下圖所示:
- 阻塞后什么時候恢復運行呢
情況1:有對應的網絡數據到來
首先我們看下網絡分組到來的內核路徑,網卡發起中斷后調用netif_rx將事件掛入CPU的等待隊列,并喚起軟中斷(soft_irq),再通過linux的軟中斷機制調用net_rx_action,如下圖所示:
注:上圖來自PLKA(<<深入Linux內核架構>>)
緊接著跟蹤next_rx_action
緊接著tcp_v4_rcv:
在這里__wake_up_common將停在當前wait_queue_head_t中的進程喚醒,即狀態改為task_running,等待CFS調度以進行下一步的動作,如下圖所示。
情況2:設定的超時時間到來
在前面調用sk_wait_event中調用了schedule_timeout
process_timeout函數即是將此進程重新喚醒
原文鏈接:
https://my.oschina.net/alchemystar/blog/1791017