Re: coming out of perl script after 10 min.

[kielstirling]

Try using a loop and sleep. You may even like to fork a child to do the work.

#!/usr/bin/perl

use Modern::Perl;
my $sec = 0;

while($$) {
        # Do something. May want to fork a child to do the work.
        say "running...[$sec]";

        exit if $sec == 600;
        sleep 1;
        $sec++;
}

[afoken]

Bad idea, unless your perl port lacks a working alarm. alarm works without active waiting, and sleep 1 does not always sleep exactly one second.

Quoting perlfunc:

On some older systems, it may sleep up to a full second less than what you requested, depending on how it counts seconds. Most modern systems always sleep the full amount. They may appear to sleep longer than that, however, because your process might not be scheduled right away in a busy multitasking system.

Alexander

[BrowserUk]

1. alarm works without active waiting,

   Since the advent of SAFE_SIGNALS; alarm won't interrupt long running opcodes.

   And the cpu requirement of the "active waiting" -- waking 1 per second:

   C:\test>perl -E"sleep 1 for 1..120; say join ' ', times"
   0 0.015 0 0
   

   0.015/120 = 0.0125% cpu usage; means that it would require 8000 of these actively waiting tasks to even register a blip on a cpu usage graph.

2. sleep 1 does not always sleep exactly one second.

   On modern OSs, the differences are tiny -- essentially the time taken between the 1 second elapsing and the process getting its next time-slice:

   C:\test>perl -MTime::HiRes=time -E"$t=time; sleep 1 for 1 .. 10*60; pr
   +int (time()-$t) - 10*60"
   601.386687040329
   

   601.386687040329 - 600 / 600 = 0.002311145067215. A couple of milliseconds

   Which means that after 10 minutes of waiting, those tiny differences will have accumulated such that you've ended up giving the user a whole extra second in which to respond. Big deal.

   But the kicker is: alarm will suffer from the essentially the same delays and inaccuracies! Once the system timer times out and sets the flag in the kernel thread structure; it still won't run until it filters its way to the top of the schedulers list of run-eligible threads.

Re-reading the post to which you responded and the OP; the former is almost certainly not a solution to the latter -- but definitely not because of the reasons you cite. They are just sweating the small stuff whilst ignoring the bigger picture.