Timer.periodic() stacks and fired a lot of events at once after computer resumes from long sleep (server-side)

[DartBot]

This issue was originally filed by tomy...@potix.com

---

For example, run the following code and put the machine to sleep for a while and wake it up. You'll find a lot of events fired at once.

import "dart:async";

void main() {
  new Timer.periodic(const Duration(seconds:1), (_) {
    print(">>${new DateTime.now()}");
  });
}

Of course, it still follows the spec. However, I don't think it is good since it means the developers have to filter out such kind of extra events to avoid choke up the computer.

BTW, JavaScript on Chrome implements setInterval() differently -- it fires only once (after resumed)

[DartBot]

This comment was originally written by andrew.m...@gmail.com

---

As you say "Of course, it still follows the spec".
This is normal behavior.

However, I don't think it is good since it means the developers have to filter out such kind of extra events to avoid choke up the computer.

It is good.

Here is an example of accurate timer (class PeriodicTimer).
Not tested. Only as example.

==================
import "dart:async";
import "dart:math";

void main() {
  var count = 0;
  var msec = 100;
  var rnd = new Random();
  Stopwatch sw;
  new PeriodicTimer(new Duration(milliseconds: msec), (Timer timer) {
    if (sw == null) {
      sw = new Stopwatch();
      sw.start();
    }

    print(sw.elapsedMilliseconds);
    if (count++ == 5) {
      timer.cancel();
    }

    block(rnd.nextInt(msec));
  });
}

void block(int msec) {
  var sw = new Stopwatch();
  sw.start();
  while (sw.elapsedMilliseconds < msec);
  sw.stop();
}

class PeriodicTimer implements Timer {
  Duration period;

  Function _callback;

  int _inMicroseconds;

  bool _isActive = true;

  Stopwatch _sw;

  Timer _timer;

  Zone _zone;

  PeriodicTimer(this.period, void callback(Timer timer)) {
    _callback = callback;
    _inMicroseconds = period.inMicroseconds;
    _zone = Zone.current;
    _timer = _zone.createTimer(period, _handler);
    _sw = new Stopwatch();
    _sw.start();
  }

  bool get isActive {
    return _isActive;
  }

  void cancel() {
    if (_isActive) {
      _isActive = false;
      _sw.stop();
    }

    _timer.cancel();
  }

  void _handler() {
    var lag = _sw.elapsedMicroseconds - _inMicroseconds;
    if (lag < 0) {
      lag = 0;
    }
    _sw.reset();
    _zone.runUnaryGuarded(_callback, this);
    if (!_isActive) {
      return;
    }

    var elapsedMicroseconds = _sw.elapsedMicroseconds;
    var microseconds = _inMicroseconds - (elapsedMicroseconds + lag);
    if (microseconds < 0) {
      microseconds = 0;
    }

    var duration = new Duration(microseconds: microseconds);
    _timer = _zone.createTimer(duration, _handler);
    _sw.reset();
  }
}

==================

Output:

0
97
201
301
401
501

[DartBot]

This comment was originally written by tomy...@potix.com

---

Sorry but, with single thread model (as Dart adapts), how can we have an accurate timer? It depends on the computer's workload, doesn't it?

Another question: when compiling to JS, will Timer.periodic() behave the same way as we have in Dart VM (i.e., firing all stacked events at once)? Or, it is translated to setInterval() and has a different behavior?

Personally, I'm fine with either case; it is straightforward to handle either case. However, it is just counter-intuitive to me -- I learned it after finding it consumes all my resources in the test environment. It is better to state it clearly on dartdoc.

[anders-sandholm]

Added Area-Library, Library-Async, Triaged labels.

[lrhn]

This is indeed an unfortunate side-effect of the isochronous timer the VM uses.
JS timers are really rescheduling timers that reschedule themselves after the the callback has been executed. That means that a setInterval(f, 100) will always trigger with more than 100ms interval between events. The more loaded the system, the more timing will slip over time.
The VM uses a timer that for a 100ms interval attempts to run events at every n*100ms, delaying each event individually. That's better if you actually want to do something ten times each second, but is problematic that if you manage to delay everything for 5 seconds, you will get 50 events immediately afterwards in order to catch up with the timer.

Both timers have their uses, but it's unfortunate that we have different behavior between the two platforms.

We could consider creating a Timer.isochronous(Duration,action) constructor and make the default Timer constructor match the JS behavior. Maybe even allow the isochronous timer to skip events if it gets behind, and pass the number of skipped events as an argument to the callback - so just calling with 500000 as an argument instead of calling 500000 times when waking after sleep.

---

Removed Type-Defect label.
Added Type-Enhancement label.

[rmacnak-google]

See also #25055