我知道程序員在線程和並行編程方面通常不是那麼容易，所以這是一個優先考慮的問題。爲什麼在多線程服務器中重複（2）偵聽套接字？
在線程服務器應用程序的偵聽套接字上調用dup（2）似乎有一個相對被接受但未知的好習慣。我瞭解「無分享」線索的一般原則，以避免種族情況而放心。我的問題是：如果內核已經在接受（2）返回值上互相排斥，那麼爲什麼有趣的是重複（2）監聽套接字？如果它真的是一個改進，套接字何時應該dup（2）-ed：bind（2）之後或listen（2）之後？
是的內核確保只有一個進程/線程將被併發調用到accept。如果你想正確使用它，那麼你需要在bind和listen之後進行。在bind之後，因爲你想分享一個綁定的服務器套接字... listen之後，爲每個人正確配置積壓。
現在這是一個設計問題：您可能更喜歡讓一個接受線程在其他線程池中調度工作（然後您需要自己管理一個池），或者讓併發接受線程並將系統的負擔。第一種設置比較複雜，但讓您對平衡有更好的控制。第二個更簡單明瞭，但並不能控制平衡。
有見地，但仍然爲什麼dup（2）？ – thodg
也許是因爲在線程終止的情況下，誰可以決定關閉？如果每個線程都有自己的描述符，代碼就簡單多了？使用'dup'當然不是強制性的。 –
在快速搜索中找不到這種做法。看起來對我來說毫無意義。 'dup'只創建一個新的整型句柄，並且複製一些相對不重要的位標誌（或者只是一個），文件/套接字數據的大量文件描述*仍然是共享的。 –
我想這可能與關閉（2）競賽條件有關？ – thodg
通常情況下，服務器不會關閉偵聽套接字，但如果出於某種原因需要，那麼可能會重複它可能是合理的。 –