c - 为什么在多线程服务器中使用 dup(2) 监听套接字？

Question

我知道程序员通常对线程和并行编程并不那么容易，所以这是专家优先考虑的问题。

在线程服务器应用程序的监听套接字上调用 dup(2) 似乎是一个相对公认但鲜为人知的好习惯。我了解“不共享”线程的一般原则，以便安心避免竞争条件。

我的问题是:如果内核已经对 accept(2) 返回值进行了互斥，那么 dup(2) 监听套接字到底有什么意义呢？

万一它真的是一个改进，什么时候应该 dup(2)-ed 套接字:在 bind(2) 之后还是在 listen(2) 之后？

Answer 1

是的，内核确保只有一个进程/线程会在并发调用accept 时得到服务。如果你想正确使用它，那么你需要在 bind 和 listen 之后进行。在 bind 之后因为你想共享一个绑定(bind)的服务器套接字...在 listen 之后为每个人正确配置 backlog。

现在是设计问题:您可能更喜欢让一个接受线程在其他线程池中分派(dispatch)工作(然后您需要自己管理一个池)，或者有并发接受线程并承担负担在系统上。第一个设置起来更复杂，但可以让您更好地控制平衡。第二个要简单得多，但不会让您对平衡有任何控制。