|
in reply to Timeouts: Any alternative to alarm in Win32?
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.
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.
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.
|
Re^2: Timeouts: Any alternative to alarm in Win32?
by salva (Canon) on Dec 03, 2008 at 14:18 UTC
|
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. | [reply] |
|
|
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.
| [reply] |
Re^2: Timeouts: Any alternative to alarm in Win32?
by ikegami (Patriarch) on Dec 03, 2008 at 18:33 UTC
|
$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 );
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 ) );
}
| [reply]
[d/l]
[select] |
|
|
Is there any advantage ...
That is both easy and difficult to give a straight answer to.
- I've used variations of that successfully.
- 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.
| [reply]
[d/l] |
|
|
can_read() sometimes (often?) returns true when nothing is available.
Well that's problematic! I know it returns true when the handle has been closed. That's a good thing. sysread returns zero allowing you to handle disconnects. But I presume that's not what you mean.
I simply don't know if IO::Select suffers the same limitations as select, but I suspect that it probaly does.
IO::Select is just a thin wrapper for select that handles packing and unpacking the bit vectors for you. If it affects select, it affects IO::Select.
Mixing select with buffered IO seems to give unreliable results.
As documented. select translates into a system call and pays no attention to Perl's buffers.
I'm very shy of using select or IO::Select in conjuction with blocking IO (the diamond operator and friends).
As you should be. The diamond operator does buffered I/O which is incompatible with select.
when I get bitten a few times, I tend to get shy.
It wasn't a trick question. I have little real-world experience in the matter. Thanks for the info.
| [reply]
[d/l]
[select] |
|
|
# If select() said data is available, but it
# was not, it means the connection was lost.
I interpret this to be that IO::Select on a blocking socket will falsely return "data available" if the OS TCP socket is in one of the disconnected states.
Another comment:
# IO::Select sometimes returns undef
# instead of an empty array.
So beware of that..
And a third one about alarm() and can_read():
Alarms are silently cancelled after
IO::Select->can_read() is called.
Of course, $SIG{ALRM} and signals in general is usually busted in many other ways, so you probably avoid a lot of trouble by steering clear of signals completely, making this less of an issue. Net::Wire10 uses threads::shared and a shared instance variable for signaling.
| [reply]
[d/l]
[select] |
Re^2: Timeouts: Any alternative to alarm in Win32?
by jbbarnes (Novice) on Dec 04, 2008 at 00:11 UTC
|
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.
| [reply]
[d/l] |
|
|
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.
| [reply]
[d/l] |
|
|
Yes, 0x8004667e did work under Linux, which actually surprised me. So the ioctl line works for both platforms, though the timeout doesn't.
| [reply] |
Re^2: Timeouts: Any alternative to alarm in Win32?
by Anonymous Monk on Dec 04, 2008 at 02:01 UTC
|
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?
| [reply] |
|
|
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.
| [reply]
[d/l]
[select] |
|
|
Again, thanks for giving me a solution that will work. I'll put in conditional code if that's what it takes. I have just been surprised and pleased that I've been able to avoid it so far.
I've got a full GUI program with lots of widgets (in TK) and a lot of network-based functionality that is 95% complete, and working on both platforms using the same code. I wanted to see how close I could get to 100%, and didn't expect to get this far. But even if I've got to add conditional code to a subroutine, all the high-level code is still nice and clean. And that's good enough for me.
I am highly impressed with the response of the perlmonk community.
| [reply] |
|
|
