1)因為nginx的worker進程都是master進程fork出來的，繼承了監聽句柄。

2)nginx實現了一個鎖，work進程競爭，誰獲取鎖，誰accept連接。######正解！######自己頂一下######

引用來自“火星人”的答案

1)因為nginx的worker進程都是master進程fork出來的，繼承了監聽句柄。

2)nginx實現了一個鎖，work進程競爭，誰獲取鎖，誰accept連接。

不是使用select方法?

######類似 進程池######

引用來自“ZYud”的答案

引用來自“火星人”的答案

1)因為nginx的worker進程都是master進程fork出來的，繼承了監聽句柄。

2)nginx實現了一個鎖，work進程競爭，誰獲取鎖，誰accept連接。

不是使用select方法?

工作進程的事件處理方式是可選的，在編譯的時候配置即可，windows下用的是select，linux下默認用的是epoll或者kqueue。

######

引用來自“火星人”的答案

1)因為nginx的worker進程都是master進程fork出來的，繼承了監聽句柄。

2)nginx實現了一個鎖，work進程競爭，誰獲取鎖，誰accept連接。

可是按道理說一個端口可是有一個應用的多個進程同時占用，但只能被一個進程所監聽的呀！

一般情況下都是master進程負責監聽，將任務分配給不同的子進程，即使是master進程fork出來的，也只是或得那個socket的句柄，也并未真正獲得監聽句柄吧！

追問一下：多個進程可以監聽同一個端口，豈不是不同的應用可以監聽同一個端口！

能幫我寫個簡單的c例子么？

######

引用來自“痞子湯”的答案

類似 進程池

進程池貌似跟這個是兩碼事兒吧

######

引用來自“火星人”的答案

1)因為nginx的worker進程都是master進程fork出來的，繼承了監聽句柄。

2)nginx實現了一個鎖，work進程競爭，誰獲取鎖，誰accept連接。

對于第二點，如果他是這么實現的，豈不是性能是master進程負責監聽分配任務的方式底，畢竟master的事兒沒少做，還有資源競爭的代價在里面

######

多個進程可以監聽同一個端口，豈不是不同的應用可以監聽同一個端口！

兩個完全獨立的進程 ， 和 fork 出來的父子進程是有區別的吧。 ?再說我覺得和進程池有 點類似，圖已經表明

在accept 之前你 fork 一堆子進程，在子進程內進行 accept 應該莫有問題吧

######個人理解

總結

以上是生活随笔為你收集整理的linux父子进程字写父读无效,linux父子进程的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。