As suggested above, for sockets you can set the handle (temporarily if preferred) to non-blocking and then use sysread to perform unbuffered IO:

#! perl -slw
use strict;
use IO::Socket;

my $buffer = '';
sub timedReadline {
    my( $handle, $timeout ) = @_;
    my $state = 1;
    ioctl( $handle, 0x8004667e, \$state );
    my $end = time() + $timeout;
    while( time() < $end and $buffer !~ m[\n] ) {
        my $read = sysread( $handle, $buffer, 100, length( $buffer ) )
+;
        sleep 1;
    }
    $state = 0;
    ioctl( $handle, 0x8004667e, \$state );
    my $n = 1+index $buffer, "\n";
    return unless $n;
    return substr $buffer, 0, $n, '';
}

my $server = shift;
my $fh   = IO::Socket::INET->new($server);

my $line = timedReadline( $fh, 5 );
die "***timeout***" unless $line;

print "Got: $line";
print scalar <$fh>; ### Normal blocking read

__END__
C:\test>junk7 localhost:54321
Got: You're connected

Goodbye


C:\test>junk7 localhost:54321
***timeout*** at C:\test\junk7.pl line 26.
[download]

If you dump the idea of POSIX-compatibility (which on Win32 is tenuous at best, and frustratingly limited otherwise), then the OS provides many mechanisms for achieving timed reads and writes.

Perhaps the simplest is using SetCommTimeouts() which ought to be usable on any type of handle--terminals, files, sockets etc.--and should be usable via Win32::API and realisable as a module that exports a simple function (saysetTimeout( $fh )), but my quick attempt using Win32API::File::GetOsFHandle() to obtain the native filehandle underlying the Perl equivalent has so far been unsuccessful. But then, I've been unsuccessful in using GetOsFHandle() for other purposes in the past.

If I find the time this week, I'll try to knock up an XS or Inline::C version and see how I get on with that.

Establishing the TCP connection and resolving the host name are still done synchronously in your code and the maximum 5s timeout set in the OP may be surpassed.

That's why I was suggesting POE... though, if I recall correctly, there was some limitation on Windows regarding asynchronous TCP connection establishing, so maybe even POE will not be enough.

Establishing the TCP connection and resolving the host name are still done synchronously in your code

True. Again, if you use the native Apis for DnsQueries() and establishing TCP connections then this is easily resolved, but no access is provided when working through Perl's POSIX-compatibility emulations.

As I understand it, the alarm method doesn't work properly on *nix unless you disable safe-signals--and that's inherently dangerous to perl's internals.

That's why I was suggesting POE...

Kind of like recommending the use of an 18-wheeler to fetch the milk. Feasible but....

If POE had solutions to timing out the TCP SYN-WAIT and DNS Query problems on Win32, then it would be far better to extract them and make them available for use by non-event driven code, than to require a BSc (O.Eng.) to gain access to them.

Of course, it would require a Master's Degree in OverEngineering, and the patience of a saint, to wade through the 600+ POE modules trying to locate those solutions. Even if they existed.

---

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."

$handle is a socket, right?

Is there any advantage to

my $state = 1;
ioctl( $handle, 0x8004667e, \$state );
my $end = time() + $timeout;
while( time() < $end and $buffer !~ m[\n] ) {
    my $read = sysread( $handle, $buffer, 100, length( $buffer ) );
    sleep 1;
}
$state = 0;
ioctl( $handle, 0x8004667e, \$state );
[download]

over

my $sel = IO::Select->new($handle);
my $end = time() + $timeout;
while( $buffer !~ m[\n] ) {
    my $left = $end - time();
    last if $left <= 0;
    last if !$sel->can_read($left);
    my $read = sysread( $handle, $buffer, 100, length( $buffer ) );
}
[download]

Is there any advantage ...

That is both easy and difficult to give a straight answer to.

1. I've used variations of that successfully.
2. I've tried using IO::Select with blocking sockets and had mixed success.

   can_read() sometimes (often?) returns true when nothing is available.

   Mixing select with buffered IO seems to give unreliable results. Which might be explained by the notes and warning in perlfunc (or not?).

   Note: on some Unixes, the select(2) system call may report a socket file descriptor as "ready for reading", when actually no data is available, thus a subsequent read blocks. It can be avoided using always the O_NONBLOCK flag on the socket. See select(2) and fcntl(2) for further details.

   WARNING: One should not attempt to mix buffered I/O (like read or <FH>) with select, except as permitted by POSIX, and even then only on POSIX systems. You have to use sysread instead.

   With non-blocking IO, false can_reads are nothing more than an annoyance. With blocking IO, they can be a infinite wait. (Or as it was called in my Mech.Eng days, a 'long wait', which is exactly what the unsuspecting apprentice experienced when he was sent to the stores to get one :)

   Mixing non-blocking and blocking IO is useful. Sometimes you don't want to wait more than a few seconds to discover that the server isn't going to respond, but once it has responded, you're prepared to wait whilst it makes up its mind what it will say next. Using a timed initial read saves waiting forever, but falling back onto the built-in blocking IO and all its conveniences, is useful once the conversation is in progress.

   I simply don't know if IO::Select suffers the same limitations as select, but I suspect that it probaly does.

Essentially, having seen can_read() return true when nothing was available, and had the code enter an infinite read state on several occasions (generally when my ISP decided to timeout my connnection), I'm very shy of using select or IO::Select in conjuction with blocking IO (the diamond operator and friends). Maybe I'm talking out of my a***; maybe I've just been 'unlucky'; but that's my experience.

And you know, one of the definitions of madness is doing the same thing over and over and expecting the outcome to be different. Since I do not consider myself to be mad (that's another strong indicator :), when I get bitten a few times, I tend to get shy.

---

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."

So far, this seems to work very well under Win32. I will test it under Linux when I get back to my office. Thanks a lot.

One question: Do you see any problem with removing the sleep 1; line from the loop? This code will be part of a loop itself to test the response of about 150 machines. I can normally get responses from up to ten machines per second. With the sleep line, that will drop it to maybe one machine every couple of seconds, which is a big performance hit. So far it appears to work reliably without the sleep line.

Do you see any problem with removing the sleep 1; line from the loop?

Well, without it, the loop will burn 100% cpu. If you need to go more quickly when the response is available more quickly, use Time::HiRes::usleep and say 25 milliseconds. (Or select<c>undef, undef, undef, 0.025;</c. would do.)

It'll avoid maxing the cpu but cut the minimum delay to 1/40th. Vary the number to see what you find acceptable. As there is IO involved, I doubt you'll go much more quickly with less than 25 millseconds.

I will test it under Linux when I get back to my office.

Be aware that I have no idea whether that ioctl number (0x8004667e), which is the key to the approach, will work on any system other than Win32. It might, but don't be surprised if it doesn't. Alternatively, if it does, please post to let me (us) know. It's always good to know these things.

---

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."

Okay, so I have now had a chance try this under both Win32 and Linux. The results are the opposite of my original code. This code successfully times out under Win32, but not under Linux. You have to wait 20+ seconds if you connect to a non responsive host.

I suppose I could write two separate subs and key off which OS it's running under. Or incorporate the alarm code (that works under Linux) into this for a belt-and-suspenders approach to breaking the call. So I do have a workable, if not gangly, solution.

But can you see a reason why this shouldn't also work under Linux?

But can you see a reason why this shouldn't also work under Linux?

Are ioctls platform portable? I have no idea. There is probably a POSIX-architected method for switching the blocking/non-blocking state of a socket. From a quick scan, maybe sockopt() in IO::Socket?

To be honest, I think I would just use if( $^O == 'mswin32' ) {...} else {...} and have done with it.

<Aside:>

When you write cross-platform code, there will always be conditional code, but the lower the level at which you try to apply the conditional: a) the more frequent it will be required; b) the harder it will be to maintain.

I've seen code (some of it in the perl core, others in perl modules), where every 3 or 4 lines of actual operational code is wrapped in some platform conditional. The result is that sometimes half a source files 'weight' is the compile-time conditions themselves. This is a nonsense.

Far better to have one file per platform (or flavour of), and a small file that conditionally incorporates the appropriate one at compile-time. Each platform dependant file is free of conditionals and can fulfill its function 'natively' without regard to the constraints of others.

People do (and will) claim that this violated the once and once only principle, and it does. But the benefits outweight the drawback--especially when it comes to maintainance, which is the "people's beef against it--because the clarity is provides, and the freedom from artificial constraint it avails, far outweights the cost of c&p code re-use.

(Sigh!}(Sorry merlyn). This is one one those truths that freshly minted CS-majors will not understand, and will argue against vociferously, until they are no longer newly minted, and are encountering their (5th, 15th, 50th) CS-dogma-optimal, every-3rd-line-is-an-OS-conditional piece of code. And then they'll recognise the wisdom behind these words.

But that takes 5 to 15 years of post-college experience, and those prepared to entertain debates on those (extended) timescales are few and far between these days. In the advertising trade, they attempt to measure and maximise our google;//advertising "attension span" (It's annoying, but illuminating to follow and read a few of those links),.

Depending upon which links you choose to read, the consesus (wet finger in the air), is that it has dropped from around 12 minutes in the 1960s, to around 5-75 seconds today depending upon context. Computers are very good (and very fast) and following deeply nested sets of rules and conditions. Human beings are not. The programmer that can maintain a sense of which of 2 or 3 conditionals is concurrent at any given time, is a very rare animal. Following 4 or 5 compile-time conditions in a single file in neigh impossible. Six is!

<Rant off>

---

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."

Yeah, signals under win32 are known to suck. There's probably a way to do it in the actual windows libraries. If you can find that you can probably use the Win32 module to pull up the native windows ... um... alarm-substitute.