Comment 1 for bug 681778

Related bug: https://bugs.launchpad.net/libmemcached/+bug/583031

There are two places in the library where this code appears:

1) in connect.c:23-24 (connect_poll()), where it tries to connect to the remote socket;
2) in io.c:60-61 (io_wait()), where it waits for a blocked socket to become ready while transmitting data.

I'd like to point out that the library _always_ sets O_NONBLOCK on the socket, regardless of the behavior set by the user. The NO_BLOCK behavior only sets a linger structure for the socket for graceful socket shutdown. With this considered, the beforementioned code fragments are there to *simulate* blocking behavior by setting infinite poll timeouts on socket operations in non-blocking mode.

But in the current version (0.44), those two code fragments actually perform _opposite_ things - in the connect() part it sets infinite poll timeout for nonblocking mode, and in transmitting part it sets infinite poll timeout for blocking mode, which is weird.

To get the intended behavior, as I see it, both code fragments should set infinite timeouts for blocking mode to simulate completely blocking socket calls with nonblocking socket setup. But this approach is also flawed, because in that case we would get insane timeouts in this 'pseudo-blocking' mode.

With all that considered, I recommend removing blocking mode completely and use reasonably large user-set timeouts to achieve the same results.