Use the hard setting to make sure that the period is constant.

It can use Time:HiRes if you have it.

Thanks. This seems to mostly work (useful module). I did set hard to 1, but I am still seeing timer events "creep" forward at about .5 seconds/minute. Any ideas?

Update: The documentation says that the interval attribute is added to the time-to-execute (called at) after the callback returns. That means that the interval really is interval+time_taken_by_callback. So, the question really is, how do I make the interval just interval?

That's what hard is supposed to be for (not adding interval after, but before). Make sure you include Time::HiRes. From the manpage:


If the "hard" flag is set, the event will be
queued for execution relative to the last time the
callback was invoked.  However, if "hard" is false the
new timeout will be calculated relative to the current
time (this is the default).
[download]

If you set repeat and hard, it shouldn't creep. I start up my samplers parked, set the at and interval, and then start them.

How fast are you getting callbacks? If you are taking too long in some of the callbacks, you could bump the callback time. Make sure that your callback action can never overlap the next callback by either speeding up the callback or slowing down the rate. Also, you might try setting debugging on either globally or on the watcher; there are diagnostics printed as to the actual times between callbacks, etc.

my $t0=time();
while(1){
  # do processing 
  # ..

  # sleep till next polling interval.
  sleep 60-(time()-$t0)%60;
}
[download]

g r i n d e r

Normally that would be a good solution. Unfortunately, this script does the following:
1. Read in a (possibly) very large file and process it.
2. Process and plot data every minute.
The data from phase 1 is needed in phase 2. I actually plan on running the script from init...

I recommend mixing solutions.

Run the script from a cron.

However have the script first try to grab a lock, if it can then it is the only copy running so proceed. If it cannot then exit immediately. Basically the same idea as Highlander - allow only one invocation at a time of an expensive CGI script however exiting is to be expected.

I believe that you will find this approach significantly better for dealing with sporadic problems (lost network connections, unexpectedly high load killing a script, needing to move the script and not losing fact of the detail that it is still in init, etc). It does not solve the problem at hand though.

Can't you just do:

$|= 1;
my $next= time() + 60;
while( 1 ) {
    print "\a";
    sleep $next-time();
    $next += 60;
}
[download]

If that one second turns out to be too much of a problem, then you can use the high-res equivalent:

use Time::HiRes;
$|= 1;
my( $next, $us )= gettimeofday();
while( 1 ) {
    print "\a";
    $next += 60;
    usleep tv_interval( [$next,$us], [gettimeofday()] );
}
[download]

Thanks. I used effectively the Time::HiRes version, but with sleep and time as they give good fractional values.

#!/usr/bin/perl -w
use strict;
use Time::HiRes qw (usleep);
$|=1;
my $duration = 2; # seconds between job starts
my $maxsecs = 30;
my $tinit = my $t0 = time; my $t1;
while (1) {
  $t1 = time;
  last if $t1-$tinit > $maxsecs;
  if ($t1-$t0 >= $duration) { # if delta-t >= d secs
    &act;
    if ($t1-$t0 > $duration+1) { print "(",$t1-$t0-$duration,")" };
    $t0 = $t1;
  }
  &waitfortick;
}

sub act {
  print "tick\n"; `boop`; # same 100% volume
}
sub waitfortick {
  print ".";
  #&sleepwait; # try these three separately
  #&selwait;
  &hireswait;
  `beep`; # from xtune, does wave -d 0.01 -f 250 -l 30
}
sub sleepwait { # tick approx 1 sec
  sleep 1;
}
sub selwait {
  select(undef, undef, undef, 0.10); # wait approx 100 millisecs
}
sub hireswait {
  usleep 100000; # sleep 100,000 microsecs if you have usleep
}
[download]

IMHO, being half a second off doesn't matter in this situation (measuring "system data"). But if the situation were different (scientific data) a fraction of a second could be very important.

In this situation the main thing that needs to be avoided is drift. If you want 60 second intervals, but you have 60.5 second intervals, those 0.5 seconds will add up and you will creep away from where you want to be. In an hour, it'll be off by 30 seconds, etc... What you need is some way of compensating (see all the good solutions above) so that the 0.5 second error doesn't accumulate.

$|= 1;
my $i;
my $start_time = time;
my $period = 60;
while (1) {
    print time, "\n";
    my $next_sleep = ($start_time + $period * ++$i) - time;
    sleep $next_sleep;
}
[download]

   MeowChow                                   
               s aamecha.s a..a\u$&owag.print