4 ms·

The semantics around close() are as they are not because of issues around exit, but because of shared descriptors. Calls that duplicate descriptors such as for

The semantics around close() are as they are not because of issues around exit, but because of shared descriptors. Calls that duplicate descriptors such as fork() or dup() will result in multiple descriptors which refer to the same network socket. These sockets need to be able to be closed individually via close() without actually shutting down the socket or modifying the socket state. If close() terminated a connection ala shutdown() then it would be impossible for a process with a network socket to fork a temporary subprocess. A different call is necessary to indicate that you wish to terminate the underlying network socket state.

jart 5y ago
Usually when people criticize UNIX i/o behavior for not being proper what they want is for it to do that thing NT does where processes freeze indefinitely at the first sign of trouble, and you have to pull out the task manager and kill the thing. Nice thing about UNIX is pretty much the only time things get that bad is when you implement sigchld wrong, and the times when we want that behavior, like with linger, we can specify the number of milliseconds it should hang. In fact, NT is so zealous about the process freezing thing that even when it comes to the signals it's required to be able to deliver by the ANSI C standard it will spawn a thread in your program just to do it. Being able to drop connections yolo style without the kernel having strong opinions is pretty important if, for example, your app is getting attacked by a slowloris and you need to shed resources while responding to requests from the main process. That's why proper operating systems are rarely production worthy.
- throwaway09223 5y ago
  Yes, as succinctly captured by the "worse is better" philosophy: https://www.jwz.org/doc/worse-is-better.html https://www.jwz.org/doc/worse-is-better.html
  - grzm 5y ago
    Or, from Richard Gabriel, the less-HN-hostile source: - https://www.dreamsongs.com/RiseOfWorseIsBetter.html https://www.dreamsongs.com/RiseOfWorseIsBetter.html - https://www.dreamsongs.com/WorseIsBetter.html https://www.dreamsongs.com/WorseIsBetter.html
    - jart 5y ago
      Those better engineers picked the wrong hill to die on with EINTR since it was never worse. It harmoniously reflects the way hardware works and hasn't threatened UNIX's long-term survival. His ideas could be more appropriately applied today to Node and Rust which made a devil's bargain adopting a quadratic packaging model.

jart 5y ago

Usually when people criticize UNIX i/o behavior for not being proper what they want is for it to do that thing NT does where processes freeze indefinitely at the first sign of trouble, and you have to pull out the task manager and kill the thing. Nice thing about UNIX is pretty much the only time things get that bad is when you implement sigchld wrong, and the times when we want that behavior, like with linger, we can specify the number of milliseconds it should hang. In fact, NT is so zealous about the process freezing thing that even when it comes to the signals it's required to be able to deliver by the ANSI C standard it will spawn a thread in your program just to do it. Being able to drop connections yolo style without the kernel having strong opinions is pretty important if, for example, your app is getting attacked by a slowloris and you need to shed resources while responding to requests from the main process. That's why proper operating systems are rarely production worthy.

throwaway09223 5y ago
Yes, as succinctly captured by the "worse is better" philosophy: https://www.jwz.org/doc/worse-is-better.html https://www.jwz.org/doc/worse-is-better.html
- grzm 5y ago
  Or, from Richard Gabriel, the less-HN-hostile source: - https://www.dreamsongs.com/RiseOfWorseIsBetter.html https://www.dreamsongs.com/RiseOfWorseIsBetter.html - https://www.dreamsongs.com/WorseIsBetter.html https://www.dreamsongs.com/WorseIsBetter.html
  - jart 5y ago
    Those better engineers picked the wrong hill to die on with EINTR since it was never worse. It harmoniously reflects the way hardware works and hasn't threatened UNIX's long-term survival. His ideas could be more appropriately applied today to Node and Rust which made a devil's bargain adopting a quadratic packaging model.