Beefy Boxes and Bandwidth Generously Provided by pair Networks
No such thing as a small change
 
PerlMonks  

Timeouts: Any alternative to alarm in Win32?

by jbbarnes (Novice)
on Dec 03, 2008 at 10:44 UTC ( #727625=perlquestion: print w/replies, xml ) Need Help??

jbbarnes has asked for the wisdom of the Perl Monks concerning the following question:

Esteemed Monks,

It seems that ActiveState's Win32 implementation of alarm will not terminate blocking system calls. Consider this brief example:

#!/usr/bin/perl use IO::Socket; $SIG{ALRM} = sub {print "Timeout\n"; die;}; my $server = shift; alarm 5; eval { my $fh = IO::Socket::INET->new($server); my $line = <$fh>; };

You can run this such as "test.pl smtp.myisp.com:25" to return your ISP's mail server ID. Under Linux, the alarm will break in after 5 seconds with no response. Under Win32, using alarm will not interrupt the process.

Every Perl networking book I have recommends this technique to handle timeouts, but you are stuck with a 20+ second wait under Windows.

Is there any other way to get control back faster? Perhaps a way to specify a timeout value associated with the read command?

Thanks for your advice.

UPDATE: Thank you for all the very quick and helpful answers. Yes, a lighter-weight solution is preferable. But if not possible, then any solution is better than none. This is part of a project replacing a Windows .exe with cross-platform code. So it needs to run on both Linux and the older Windows boxes. So far it has been very successful, until this snag.

There is a Timeout argument to new() when creating the socket, but apparently that only applies to connect() and accept().

Replies are listed 'Best First'.
Re: Timeouts: Any alternative to alarm in Win32?
by BrowserUk (Patriarch) on Dec 03, 2008 at 13:35 UTC

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

      $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 ) ); }
        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.

      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.

      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.
Re: Timeouts: Any alternative to alarm in Win32?
by cdarke (Prior) on Dec 03, 2008 at 12:15 UTC
    The C/C++ "native" way of doing that is to use a Waitable Timer, APIs CreateWaitableTimer, SetWaitableTimer, etc; or a Timer Queue, CreateTimerQueue and CreateTimerQueueTimer (don't-ya just love those API names). Doesn't appear to be anything on CPAN though (hummmmmm), although Time::HiRes might help.
Re: Timeouts: Any alternative to alarm in Win32?
by jettero (Monsignor) on Dec 03, 2008 at 11:50 UTC

    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.

    -Paul

Re: Timeouts: Any alternative to alarm in Win32?
by salva (Canon) on Dec 03, 2008 at 12:10 UTC
    You can use non-blocking IO, though you will have to work at a lower level... or try POE.
Re: Timeouts: Any alternative to alarm in Win32?
by zentara (Archbishop) on Dec 03, 2008 at 13:18 UTC

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: perlquestion [id://727625]
Approved by marto
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others perusing the Monastery: (5)
As of 2022-08-09 14:41 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found

    Notices?