Timeline for Can close() block?
Current License: CC BY-SA 3.0
7 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jul 6, 2017 at 14:37 | comment | added | nh2 | OK, thanks, that clarifies it. I mainly confused by the first paragraph. I have no objection to the second. | |
| Jul 5, 2017 at 20:51 | comment | added | Michael Homer | The first paragraph is marked obsolete in POSIX, but you could still encounter it. I don't know what your objection to the second is; setting SO_LINGER is exactly a case where close() can block, and your sources agree. The question is "can close() block?", not about the default behaviour. The example at the bottom of the answer was unhelpful, though. | |
| Jul 5, 2017 at 20:42 | history | edited | Michael Homer | CC BY-SA 3.0 | Remove misleading example |
| Jul 5, 2017 at 20:08 | comment | added | nh2 | On this page I have found: "A STREAMS subsystem is available for Linux, but you need to add it yourself. It is not usually included by default.". So I suspect that this answer is inaccurate. close() can block, but only if SO_LINGER is enabled with a non-0 timeout. Another useful resource is this, discussing SO_LINGER behaviour accross platforms. | |
| Jul 5, 2017 at 20:04 | comment | added | nh2 | This answer conflicts with this Quora answer that says that by default close() returns immediately and "all data is sent but this occurs asynchronously—in the background". It also conflicts with this comprehensive article. Is it possible that this STREAM topic you quote is a special case that doesn't apply for normal TCP? | |
| Jul 20, 2014 at 2:13 | vote | accept | Brian Bi | ||
| Jul 20, 2014 at 2:11 | history | answered | Michael Homer | CC BY-SA 3.0 |