alarm() on windows 2003, overview

[bonjedward]

Could someone please explain (without extreme technical details) the status of the alarm() function on Windows 2003 server? I discovered last month that it no longer works (no errors, just doesn't time out), and on a perlporter forum I read that this also applies to Windows Vista betas. But then I was puzzled to read elsewhere that alarm() is unimplemented in 5.8. for Win32. That can't be right - it works fine (5.8.3 in Windows 2000) here. So when did alarm() get implemented for Win32, and what's the time frame for a solution (if any) on Windows 2003? Could this be a deliberate attempt for Microsoft to eradicate Perl from Windows? I have lots of scripts that depend on it, and all our new servers will be running 2003.

[EdwardG]

Looking at the ActiveState sources, it seems 5.8.3 had the first Win32 implementation of alarm(). Here's the changelog comment -

[ 21901] By: nicholas              on 2003/12/13  21:22:15
        Log: Integrate:
             ...
             
             [ 21895]
             alarm() is now implemented on Win32.
             
             ...

And from looking inside win32.c it seems that win32_alarm() uses SetTimer.

And yes, the behaviour of SetTimer has changed from Win 2000 to Win 2003

On 2000 if the timeout "is greater than USER_TIMER_MAXIMUM, the timeout is set to 1."

On 2003 SP1 if the timeout "is greater than USER_TIMER_MAXIMUM, the timeout is set to USER_TIMER_MAXIMUM."

That might be your problem, maybe.

[Anonymous Monk]

15.7.1. Problem You want to sound an alarm on the user's terminal.

15.7.2. Solution
Print the "\a" character to sound a bell: 

print "\aWake up!\n";
Or use the "vb" terminal capability to show a visual bell:

use Term::Cap;

$OSPEED = 9600;
eval {
    require POSIX;
    my $termios = POSIX::Termios->new( );
    $termios->getattr;
    $OSPEED = $termios->getospeed;
};

$terminal = Term::Cap->Tgetent({OSPEED=>$OSPEED});
$vb = "";
eval {
    $terminal->Trequire("vb");
    $vb = $terminal->Tputs('vb', 1);
};

print $vb;                                  # ring visual bell
15.7.3. Discussion
The "\a" escape is the same as "\cG", "\007", and "\x07". They all cor
+respond to the ASCII BEL character and cause an irritating ding. In a
+ crowded terminal room at the end of the semester, this beeping cause
+d by dozens of vi novices all trying to get out of insert mode at onc
+e can be maddening. The visual bell is a workaround to avoid irritati
+on. Based upon the polite principle that terminals should be seen and
+ not heard (at least, not in crowded rooms), some terminals let you b
+riefly reverse the foreground and background colors to give a flash o
+f light instead of an audible ring.

Not every terminal supports the visual bell, which is why we eval the 
+code that finds it. If the terminal doesn't support it, Trequire will
+ die without having changed the value of $vb from "". If the terminal
+ does support it, the value of $vb will be set to the character seque
+nce to flash the bell.

There's a better approach to the bell issue in graphical terminal syst
+ems like xterm. Many of these let you enable the visual bell from the
+ enclosing application itself, allowing all programs that blindly out
+put a chr(7) to become less noisy.

[syphilis]

Just a minor nitpick - I think it's a little rash to assert that "it works fine (5.8.3 in Windows 2000) here".
The alarm() documentation states that "Each call disables the previous timer, and an argument of 0 may be supplied to cancel the previous timer without starting a new one. The returned value is the amount of time remaining on the previous timer".
I've never been able to get a return value of anything other than '0' on Windows 2000 - though I agree that, as a timeout mechanism, it can work fine. (Of course, if you're finding that alarm() is fully functional, then it's me that's being a "little rash" :-)

One other thought is that you might get better mileage from Win32::Process's Kill() method.

Cheers,
Rob

[bonjedward]

Thanks, I've started rewriting my programs with Win32::Process::Create(), and Wait(), and that's solved my problem. I have never examined the return values from alarm(), so it may not have been fully functional, but was quite useful nonetheless. The problem with Windows 2003 is that the timeout never occurs. I used it when calling processes that risk hanging. For example some proprietary so-called 'batch' routines that stupidly report errors with alert boxes. I started a countdown with alarm() based on expected time-to-complete, and if it timed out before the process returned, I'd kill the process to get rid of the alert box. If not, I'd cancel it with alarm(0); I also used it with Openwebload (from Sourceforge) which calls a GIS web site every few minutes and examines the result to see if a map was actually generated as a result of the call (if not, it restarts various processes). Unfortunately, if IIS is not running, Openwebload gets into an endless loop consuming 100% of CPU resources, and here alarm() was a useful safety valve allowing me to break out and kill it. So Win32::Process::Create(), and Wait() now do this, and it works fine. It will take me a while to rewrite all my scripts, though, so it is a pity that Windows 2003 has broken some useful (partially implemented) perl functions. thanks, David