[withinboredom]

I’m explicitly saying not to put timeouts in code… but you must put a timeout on a socket due to the way they work. Period. Or deal with the default, which is usually many minutes. Sockets timeout when packets haven’t been acknowledged for a long time, but you can also set an idle timeout as well.

A timeout on sockets isn’t negotiable.

[saurik]

I continue to disagree: the socket does not need a timeout, it can simply go into an infinitely held state. Take a web browser (a very typical "outgoing socket" case): there is no value in either the browser or the socket having a timeout, as, if the user decides it takes too long, they will click Stop and/or Reload, which will close the socket. "I guess the remote side didn't send me a response packet within X seconds so I'll automatically stop the load and show the user an error" does not provide any benefit and can only lead to new failure edge cases.

[withinboredom]

I’m talking about the physical socket in the kernel here. Not a hypothetical one. You can send packets (literally pulses of electricity) down it, but you don’t know if anything happened until you get packets back. By default, this is around half an hour, basically far longer than any human would reasonably wait.

My point is, you have to set this or accept the default timeout. The default is more than reasonable, anything less than minutes — with an s — is unreasonable.