Re:Don't trust default timeouts
by nitrogen on Saturday August 29, 2020 @02:39PM
(#24318401)
You sometimes won't know a TCP connection has been closed unless you try to write to it (possibly there's a select/epoll/etc way to test), so if you are using blocking I/O, you won't know that the HTTP client went away long ago.
[ Parent
| on HN ]
Re:Don't trust default timeouts
by user5994461 on Saturday August 29, 2020 @03:40PM
(#24318859)
Highly advise to turn on TCP keepalive to detect dropped connections.
Re:Don't trust default timeouts
by Matthias247 on Saturday August 29, 2020 @04:02PM
(#24318998)
Sure. But the pointer of the parent poster was that you still won't observe the error unless you are interacting with the socket again. If you have a blocking thread per request model and your thread is blocked on the database IO, then it won't look at the original request (and it's source socket) for that timeframe.
There is no great OS solution for handling this. You kind of need to run async IO on the lowest layer, and at least still be able to receive the read readiness and associated close/reset notification that you can somehow forward to the application stack (maybe in the form a `CancellationToken`)