3 ms·
Calling read() won't tell you anything if someone cut the wire or unplugged an Ethernet cable that wasn't directly connected to your machine. write() won't fai
by nly 5y ago
Calling read() won't tell you anything if someone cut the wire or unplugged an Ethernet cable that wasn't directly connected to your machine.
write() won't fail until after a bunch of TCP re-transmit timeouts have passed.
TCP keepalives can help but you have to enable them and, as I said before, doing so is different on different platforms.
Honestly, if you're doing anything remotely interactive or latency sensitive on the same thread as network I/O you need to go async.
- jstimpfle 5y agoFor the record, I am of course doing async (Or rather non-blocking) I/O. I explicitly said that it's a mistake to write blocking code. (I made an error somewhere though where I wrote "non-blocking" instead of "blocking"). (And as I described, the "green threads" kind of blocking code is a mistake just as well. And the event-driven kind (i.e. callbacks / like in Javascript) leads to messes as well, only way I see it not become a mess is pushing stuff to buffers to process messages later in a separate message processing loop with some better context etc.