1. Check.
2. I'm not sure building this functionality into this important module is worthwhile at all since the string returned from `ping` is completely arbitrary, system-dependent, and variable even during the lifetime of a system. That's bad news. Having to parse such a string from the module would be difficult if not impossible to anticipate. I don't really see a benefit of including this in a module since the user is free to call `ping` at anytime anyway and know the system specifics beforehand.

   Example:

   • Here's the ping output from a Solaris server:

     % ping www.agentm.com
     www.agentm.com  : #####
     
     www.agentm.com  :   5/5   succ. = 100.00%
     [download]

   • And the more familiar Linux-brand generic ping:

     PING worf4.agentm.com (208.185.131.199): 56 octets data
     64 octets from 208.185.131.199: icmp_seq=0 ttl=244 time=216.6 ms
     64 octets from 208.185.131.199: icmp_seq=1 ttl=244 time=216.1 ms
     64 octets from 208.185.131.199: icmp_seq=2 ttl=244 time=247.6 ms
     64 octets from 208.185.131.199: icmp_seq=3 ttl=244 time=235.3 ms
     
     --- worf4.agentm.com ping statistics ---
     4 packets transmitted, 4 packets received, 0% packet loss
     round-trip min/avg/max = 216.1/228.9/247.6 ms
     [download]

   The output is completely arbitrary and impossible to anticipate. (Note that agentm.com does not belong to me as it should! Copyright stealing bastards!)

3. alarm was a poor choice to start off with. The options I mention above are far better suited for the task. History: alarm is a very old function (much older than select) and was used for similar tasks as here. It is now best to avoid this function altogether. I can't even think of a use of it in a modern threaded system.
4. Again, if the user wants to do this, he can easily cough up a for loop to fork off ping requests, even using the module. I'd say, more than not, modules are looked towards for "good programming style", especially for beginning users. Including this would constitute teaching bad, yet functional, programming style. Honestly, again, I don't see the benefit to including this in an important module as this one. But, if you see the need to do this, perhaps name it Net::Ping::Parallel and warn about its use profusely. If you specify a number of forks less than the number of hosts to ping, you will be using some fairly heavy-duty IPC, putting reliance on yet another module and more system resources. I would definitely AT LEAST keep such code away from the standard Net::Ping. Feel free to msg me if you need additional clarification. Good luck!

AgentM Systems nor Nasca Enterprises nor Bone::Easy nor Macperl is responsible for the comments made by AgentM. Remember, you can build any logical system with NOR.