任何情况下close（）优于shutdown（）？答案

【问题标题】：Any cases Where close() is preferred to shutdown()?任何情况下close（）优于shutdown（）？
【发布时间】：2011-11-17 10:29:22
【问题描述】：

我是一个开源项目的开发人员，我一直遇到一些问题，服务器认为它已经完全响应了一个套接字（这意味着它已经发送了一个回复或关闭它以响应失败）和客户端卡在 poll() 中。经过一番研究，我发现 close() 并不总是会生成 POLLHUP 事件，但 shutdown(sock, 2) 会。

鉴于此，我正在考虑在错误处理的情况下添加一个 shutdown(sock,2) （除了 close() 调用之外）。有谁知道这会导致问题的一些原因？我在吠叫错误的树吗？我在想，如果服务器认为套接字已关闭，则客户端绝对不应该尝试使用该套接字进行任何其他操作，我想不出不添加它的理由，但我一直没有使用 tcp这么长时间的联系，并希望得到一些建议。

【问题讨论】：

我建议阅读：stackoverflow.com/questions/409783/…
大脑，这是一本有趣的读物，但它没有给我任何理由，我不想将关闭与关闭一起调用。

标签： c sockets shutdown

【解决方案1】：

您需要弄清楚为什么closeing 套接字不会导致它变为shutdown。最可能的原因是有另一个描述符访问同一个端点。只有closeing 最后一个端点会导致隐式shutdown。

你有没有dup 文件描述符？你确定它在所有子进程中都是closed 吗？如果套接字在forked 这个进程之前处于父进程中，那么父进程是否关闭了他们的副本？

【讨论】：

大卫，感谢您的建议。我有一种感觉，问题在于追查你所说的。我相信我已经从代码中删除了所有分叉以支持线程，但我会检查 dups。但是有一个问题 - close() 在正确关闭时是否总是会导致关闭？
如果关闭引用该端点的最后一个描述符，则关闭会导致隐式关闭。隐式关闭的行为取决于“关闭时停留”设置。
close 不返回错误信息。因此，它几乎不能替代shutdown。您不知道您发送的内容是否已收到。

【解决方案2】：

POLLHUP 不是测试关闭连接的正确方法。您应该测试文件描述符是否变得可读并随后返回零长度读取。这是文件结尾的定义。

【讨论】：

R，代码使用 poll() 和集合：pollset.events = POLLIN |民意调查；由于我无法控制的原因，我无法从 poll() 模型中更改它。无论哪种方式，客户端都会阻止该轮询，直到发生超时。
是的，然后检查POLLIN。 EOF 是一个零长度读取，显示为可供读取的输入。
-1 POLLHUP 是检查某些系统的正确方法（想到 MacOS）； POSIX 规范允许两者之一。所以如果你想便携，你真的需要检查POLLHUP|POLLIN。
@Chris：引文？即使你是对的，我也很确定这个答案可以解决 OP 遇到的问题。
代码确实会检查 POLLIN 和 POLLHUP（抱歉，我不小心发布了然后不得不编辑），但我的问题仍然存在。