Timeouts/timers on Win32 system

[Dovkont]

Greetings!

I have a need to implement the following:
A perl script works as server running certain application. It is connected via a socket to certain user interface, recieving a command, passing it on to the application and sending back the result. All this runs on Windows with ActivePerl.
Now, I want to make an automatic shutdown mechanism, that works on the condition of not recieving a user command for a set period of time. Then the script must run a function that shuts down the applications and takes care of auxiliary files. (As it is one when the quit command is being sent). The socket should remain active.

I have tried to find, but, apparently without success a way to do such a timer...

Thanks in advance,

Dovkont.

[NetWallah]

Have you tried the alarm SECONDS function (In an eval block) - it's usage as a timeout timer is described in perlfunc.

[PodMaster]

Hello, just a fyi

E:\>perldoc perlport|grep alarm
    alarm SECONDS
    alarm   Not implemented. (Win32)

E:\>perl -le"alarm 0"
The Unsupported function alarm function is unimplemented at -e line 1.

update: apparently, for perl 5.8.x this has changed, but perlport wasn't updated (i'll notify perl5-porters if perl-current is not up to date)

E:\>perl
local $SIG{ALRM} = sub { die "alarm!!!!" };
alarm 1;
sleep 10;
alarm 0;
__END__
alarm!!!! at - line 1.

[AcidHawk]

[Dovkont]

Unfortunately, this is not the way - since I need not only to shut the program down, but to undertake a number of maintainance procedures, that are located in a sub of the server script. Also, the Win32::Process->Wait($timeout) is waiting for the process to shutdown, and if that does not occur for $timeout, then the process is being shut down. And that is absolutely not what is needed :(

Also, alarm does not work on Windows, as far as I recall.

[Thelonius]

The best way is to use the select system call (note there are two different select functions in Perl). It's a bit easier to use it via the IO::Select module. Something like this would work:

if (IO::Select->new(SOCKETHANDLE)->can_read($timeout)) {
  do the socket read as normal
} else {
  you timed out
}

[Anonymous Monk]

use IO::Select;
my $s = IO::Select->new($socket);
while (not $done) {
    my @socks = $s->can_read($timeout);
    if (@socks) {
       read_socket();
       whatever();
    }
    else {
        close_process();
    }
}

[Dovkont]

Tried it finally, and yes, it works perfectly. Thank you very much!!!

[BrowserUk]

This isn't a fully worked solution, but it does demonstrate that it is reasonably easy to simulate the unix alarm function under Win32.

#! perl -slw
use strict;
use threads;
use threads::shared;

my $alarmFlag : shared = 0;

$SIG{__WARN__} = sub{ $alarmFlag = 1; };

sub myAlarm {
    my( $procID, $timeout ) = @_;
    async sub{
        Win32::Sleep $timeout;
        warn 'Timeout';
    };
}

myAlarm( $$, 3000 );

while( not $alarmFlag ) {
    print 'Waiting for the alarm at ', scalar localtime;
    print 'Tum te, tum te, tum';
    Win32::Sleep 1000;
}

print 'The alarm was raised', $/;

$alarmFlag = 0;
myAlarm( $$, 3000 );

while( not $alarmFlag ) {
    print 'Waiting for the alarm at ', scalar localtime;
    print 'Tum te, tum te, tum';
    Win32::Sleep 1000;
}

print 'The alarm was raised', $/;

__END__
P:\test>alarm

Waiting for the alarm at Mon Dec  8 20:03:19 2003
Tum te, tum te, tum
Waiting for the alarm at Mon Dec  8 20:03:20 2003
Tum te, tum te, tum
Waiting for the alarm at Mon Dec  8 20:03:21 2003
Tum te, tum te, tum
The alarm was raised

Waiting for the alarm at Mon Dec  8 20:03:22 2003
Tum te, tum te, tum
Waiting for the alarm at Mon Dec  8 20:03:23 2003
Tum te, tum te, tum
Waiting for the alarm at Mon Dec  8 20:03:24 2003
Tum te, tum te, tum
The alarm was raised

This could be done a lot more effectively at the perl source level, and even made more sensible by a few pretty trivail patches to the perl sources. Changing the current default behaviour for most of the signals under Win32 which is set to die for pretty much anything other than a couple of exceptions -- which is just about the strangest choice of default behaviour possible as it make it impossible to code a more compatible workaround as you never get the opportunity to trap them? Strange choice.

[disciple01]

Thanks for the replies chaps.

Bit busy at work atm on other projects will test these out in a couple of days and report.