I have never understood the point of blocking sockets. Even in a multithreading setting the socket would block indefinitely and force you to terminate the thread.
Apart from toy programs - is there a use for blocking sockets?
I have never understood the point of blocking sockets. Even in a multithreading setting the socket would block indefinitely and force you to terminate the thread.
Apart from toy programs - is there a use for blocking sockets?
Blocking sockets wake when they have data available, if you use blocking sockets you will usually have that on its own thread. The benefit you get is immediate response to incoming data. The alternative is to check the socket every n seconds (where n is the delta of your polling, if you poll at 60fps for example then n will be 16.66r-ms. This may seem a negligent amount of time, and for many application it is.
However, if we take into account a simple PING operation, the PING response could have an added latency of up-to 16ms in the worst case (in the given example).
It is entirely up-to the developer if the added latency is acceptable or not and choose which direction they wish to take, but blocking sockets can lead to (relatively) much more responsive network processing. Whether that's a requirement or not is down to what you're doing and how you implement it though, really.
n!
Apart from toy programs - is there a use for blocking sockets?
Using a blocking socket is a common and sane way to implement a server. In fact, it's pretty rare that you need non-blocking sockets in my experience.
Almost all servers I've had the pleasure of working with use socket multiplexing and blocking sockets. The code is simpler and less error-prone. Unless you've written erroneous code, it's not possible to block indefinitely on a read, because you only read when the multiplexor (select()/poll()/epoll()/kqueue() etc) indicates data is available.
if you use blocking sockets you will usually have that on its own thread