为什么在多线程服务器中重复（2）侦听套接字？

我知道程序员在线程和并行编程方面通常不是那么容易，所以这是一个优先考虑的问题。为什么在多线程服务器中重复（2）侦听套接字？

在线程服务器应用程序的侦听套接字上调用dup（2）似乎有一个相对被接受但未知的好习惯。我了解“无分享”线索的一般原则，以避免种族情况而放心。我的问题是：如果内核已经在接受（2）返回值上互相排斥，那么为什么有趣的是重复（2）监听套接字？如果它真的是一个改进，套接字何时应该dup（2）-ed：bind（2）之后或listen（2）之后？

来源

2017-06-21 thodg

在快速搜索中找不到这种做法。看起来对我来说毫无意义。 'dup'只创建一个新的整型句柄，并且复制一些相对不重要的位标志（或者只是一个），文件/套接字数据的大量文件描述*仍然是共享的。 –

我想这可能与关闭（2）竞赛条件有关？ – thodg

通常情况下，服务器不会关闭侦听套接字，但如果出于某种原因需要，那么可能会重复它可能是合理的。 –

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

现在这是一个设计问题：您可能更喜欢让一个接受线程在其他线程池中调度工作（然后您需要自己管理一个池），或者让并发接受线程并将系统的负担。第一种设置比较复杂，但让您对平衡有更好的控制。第二个更简单明了，但并不能控制平衡。

来源

2017-06-21 15:43:02

有见地，但仍然为什么dup（2）？ – thodg

也许是因为在线程终止的情况下，谁可以决定关闭？如果每个线程都有自己的描述符，代码就简单多了？使用'dup'当然不是强制性的。 –

为什么在多线程服务器中重复（2）侦听套接字？

回答

相关问题