4 ms·

> there are failure modes where nothing will notify you that the connection has been lost until you try to write() you need to either read() or write() on a co

> there are failure modes where nothing will notify you that the connection has been lost until you try to write() you need to either read() or write() on a connection to be informed that the connection was terminated or half-closed. My server application works perfectly, it reacts immediately to any state change. Did not require any special code, just monitor the read and write ends, which is what one does anyway. (Yep, this is API specific behaviour of course, but it's the only sane approach IMO, since the termination event must be sent in a synchronization with the actual channel interaction). Of course, if you're not checking for updates on both directions (read + write) because you're blocked on some blocking interface (either on the same socket or different I/O port or computation), your server won't react. The API is not to fault. The mistake was to write blocking code. That is the difference between dirty batch scripts and systems programming.

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 ago
  For 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.

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 ago
For 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.