Re: [問題] fork和slect的優缺點

看板C_and_CPP (C/C++)作者adxis (Acquire higher)時間13年前 (2012/10/01 00:34)推噓1(1推 0噓 0→)

留言1則, 1人參與討論串2/2 (看更多)

※ 引述《iversonjimmy (Effort)》之銘言： : 開發平台(Platform): (Ex: VC++, GCC, Linux, ...) : Linux : 額外使用到的函數庫(Library Used): (Ex: OpenGL, ...) : 問題(Question)： : 請問各位，fork和select都是可以做到server服務multi-client的socket程式， : 那這兩種方法的優缺點呢？ : 似乎很多人都推select，但我不太懂fork的缺點在哪？ : 當accept新的socket_fd時，就fork new child process， : 處理結束後就kill掉該child process， : 感覺兩者若要比較的話？該從哪個方向去比較優缺點呢？ : 餵入的資料(Input)： : 預期的正確結果(Expected Output)： : 錯誤結果(Wrong Output)： : 程式碼(Code)：(請善用置底文網頁, 記得排版) : 補充說明(Supplement)：從伺服器的角度來看，如果讓每個連線占用單獨的行程 (process) 由於建立行程的成本較高，能夠同時服務的連線數量就會十分受限。但是，這跟用不用 select 是兩件事情。 select 允許你監看多個 sockets，當任何 socket 的狀態變成可讀/寫時，select 會"通知"你可以對 socket 進行操作這裡使用通知其實是比較抽象的說法，簡單的 socket read 例子如下 fd_set socks; struct timval timeout = {1,0}; // ... init while(1){ any_readable = select(FD_SETSIZE, &socks, NULL, NULL, &timeout); // 上一行會 block 直到有任一 socket 變為可讀或者 timeout 發生 // 以下進行檢查並從可讀的 socket 讀取資料，處理完後繼續 select } 上面的例子修改一下就可以讓一個行程負責 select 而另一個行程負責資料處理，就需要使用 fork。 select() 是個通用但效能並不最佳的 I/O demultiplexing 方案因此版友提到的 poll 是另一個方案；另外還有 /dev/poll, epoll, kqueue, IOCP 等，都可以搭配單一行程或多行程(執行緒)來使用，時下也有許多跨平台的程式庫例如 libevent 或 boost::asio 等直接幫你包裝不同的方案，提供一致的介面。你只要根據專案需求去選擇想要的架構，至於有那些架構，可以參考 C10K 這篇老文章雖然他已經沒甚麼在維護，但還是非常值得一讀。(http://www.kegel.com/c10k.html ) 或者你可以直接去玩 ZeroMQ ，不需要支援特定應用層協定的話，他倒是很方便。 -- ※ 發信站: 批踢踢實業坊(ptt.cc) ◆ From: 118.170.79.48