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

Open 10 sockets

You are still opening the 10 sockets serially, and if the first machine isn't there, you will have to wait for the open attempt to fail--timeout--before moving on to the second...


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.
"Too many [] have been sedated by an oppressive environment of political correctness and risk aversion."
  • Comment on Re^2: Testing many devices - are threads the answer?

Replies are listed 'Best First'.
Re^3: Testing many devices - are threads the answer?
by shmem (Chancellor) on May 13, 2009 at 14:31 UTC
    you will have to wait for the open attempt to fail--timeout--

    Not true if you open the socket in non-blocking mode.

      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.

        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.