in reply to Re^4: Testing many devices - are threads the answer?
in thread Testing many devices - are threads the answer?

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.

Replies are listed 'Best First'.
Re^6: Testing many devices - are threads the answer?
by BrowserUk (Patriarch) on May 13, 2009 at 21:15 UTC

    Thanks. Looking around I see that it might be possible to use IO::Socket to obtain an IO::Socket::INET compatible handle in an unponed state. In which case it might bepossible to do the setsockopt() call to make it non-blocking before attempting to open it on Win also. I'll have to have a play with that.

    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]

In Section Seekers of Perl Wisdom