| [reply] |
Could you expand on that a little?
Maybe its a platform limitation, but how do you get hold of the socket to set it non blocking before you've opened it? Setting Blocking to 0 on the open doesn't cause the open to return immediately if the peer isn't there on my platform.
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.
| [reply] |
Linux here. Setting the Blocking => 0 makes IO::Socket::Inet->new succeed and return a handle immediately which is what I want, but the Socket may not be connected at that time. From the IO::Socket::INET pod:
Although it is not illegal, the use of "MultiHomed" on a socket which is in non-blocking mode is of little use. This is because the first connect will never fail with a timeout as the connect call will not block.
From that I conclude that it is the connect() which would cause the block in blocking mode, not the socket setup, and the connect() system call keeps running handled by the OS. My tests confirm that for my platform.
| [reply]
[d/l]
[select] |
