Consider blocking connect

[majek]

For a better usability we might consider doing two changes:

• don't allow getting a socket descriptor before calling connect
• make connect block

This would allow connect to iterate over resolved host names to check which one actually has rmq running.

[vitaly-krugl]

Another option: Add an arg to the connect() method to allow the client to specify a callback function that gets called whenever socket changes. This would enable the user to discover when it's time to switch to a different fileno.

Success of a connection may be tested after the socket becomes writeable: after the socket becomes writeable, calling getpeername() on the socket would raise socket.error with errno=EINVAL if socket connect() failed. As an alternative, sock.getsockopt(socket.SOL_SOCKET, socket.SO_ERROR) would return non-zero errno if connection failed (this call also clears the SO_ERROR value, so calling it again would return 0).

Also consider having a callback to let the user know whether puka is waiting for the socket to be readable, writable, or both. This would facilitate an event-driven mechanism for the user to interact with their I/O loop.

[jmptbl]

I take it this idea was implemented because puka's connect() currently does block, and it's a major drawback IMHO. I know puka needs better handling of multiple DNS address results, but sacrificing a non-blocking connect() is a poor trade-off IMHO. I've just committed changes to make it non-blocking in my fork, and hopefully will think of an elegant approach to handling multiple address records.