Programming

Sockets are also not available on EVERY system, does not mean you should not use them. The option is available on Windows, Linux and BSDs, haven't checked more.

Go check the POSIX specification for socket's options. The STANDARD said so.

---------- Post updated at 05:11 AM ---------- Previous update was at 04:38 AM ----------

I apologize for my rudeness.

As in abstract implementation goes, it is possible but its not very smart as it is easy to mess up, consider blocking thread unblocks (because it gets data to read) while other thread is sending and starts sending as well, you end up with borked output, or at least there will be a race condition possibility. Smart implementation should use just one thread per connection handler.

You're forgiven.

SO_RCVTIMEO has been standardized with the Single Unix Specification ("aka Unix98"). The POSIX standard that deals with socket is IEEE Std 1003.1g-2000 ("aka Posix.1g") and AFAICS setting timeout on socket is not mandatory.

A decade ago, select() was considered the most portable way to achieve timeout; as there were many unix-like systems that had sockets, but not SO_RCVTIMEO. Now 13 years after Unix98, I expect most modern system to support this option. Even if you don't work on a "archaic system", you may find this pattern in older code.

Beside this point, there might be situation where select() - or rather the modern version poll() - makes more sense. Like: variable timeout depending on the expected answer length, when the polymorphic aspect of the descriptor is used...

I checked the Linux/FreeBSD kernel source. For Linux, you're right: recv() call the poll() syscall internally. For FreeBSD, both select() and recv() are built on the tsleep() syscall.

Cheers, Loïc

There's modern systems like OSX where poll() doesn't work on a variety of things like terminals.