3 ms·
I often wonder why SO_RCVTIMEO/SO_SNDTIMEO avaiable for sockets but not for file descriptors. Setting timeout once then using classic read/write on blocking FDs
by ruslan 7y ago
I often wonder why SO_RCVTIMEO/SO_SNDTIMEO avaiable for sockets but not for file descriptors. Setting timeout once then using classic read/write on blocking FDs is easy, meaning error code handling is appropriate.
- Joker_vD 7y agoDisk file descriptors are so bizarre, if you think about it — why they still don't support any non-blocking primitive to this date? You can sorta simulate it with spawning a helper process that does "while (true) { write(stdout, read(fd)); }" or "while (true) { write(fd, read(stdin)); }" and giving it a pipe (you can epoll a pipe), but that's horrible. All single-threaded epoll-or-equivalent-based network servers hit this problem sooner or later and become multi-threaded network servers (also, there is async DNS resolution, but that's a whole separate barrel of worms).
- gpderetta 7y agoI think it is because network is inherently different from disk. A disk might be slow, but data will eventually arrive (bad disk or network mounts being the exception of course).
- nybble41 7y ago> bad disk or network mounts being the exception of course That's kind of the point. Programs shouldn't assume that any particular file is local. Any file may be hosted on a network mount, and that means network-style asynchronous interfaces should be used to access the data.