Bringing setTimeout to ECMAScript

[Wes Garland]

On Sat, Mar 19, 2011 at 12:58 PM, Mark S. Miller <erights at google.com> wrote:

> The idea is not stupid at all. It's perfectly sound. For example, the delay
> example you noticed could be made primitive and setTimeout built out of
> that. Either can be built from the other. The advantage of layering
> setTimeout on a new primitive, whether delay or <
> http://nodejs.org/docs/v0.4.3/api/all.html#process.nextTick> or something
> else, is that the new primitive can avoid spec weirdnesses already
> entrenched for setTimeout, like this 4ms clamping. Instead, this 4ms
> weirdness could just be specifically part of setTimeout's behavior.


I agree 100% - there is no requirement to make setTimeout a fundamental
building blocking; it can easily be treated as a high-level API. There is
also no need to make the base time measurement unit milliseconds -- it is
very easy to see a future where microsecond- or even nanosecond-resolution
is desirable.  (Assuming, of course, we manage to get over the current GHz
barrier to make our individual cores faster).

A base specification built on nanosecond-resolution timers gives us a
maximal timeout of 104 days with 53-bit "integers".

That said, I have to ask: is there a reason the base specification needs to
discuss time at all?  Why not just a function that returns true or false?
This still allows us to implement setTimeout in terms of Date, probably
requires less specification, and adds more power  ("is a mouse button
down?"  vs.  "is it 4 o'clock?")

In this untested example which implements setTimeout, I present a function
called enqueue, which takes as it's argument a function that returns true if
the function is to be re-interested at the end of the event queue once it
was evaluated:

function setTimeout(f, delay) {
  var when = +(new Date()) + delay;
  enqueue(function() {
    if (+(new Date()) < when)
      return true;
    if (typeof f === "string"))
      indirectEval(f);
    else
      f();
  });
}

Of course, we could make this a little cheaper by codifying moz's
Date.now(), or even having a property of the event system which is the value
of the timestamp when the current iteration of the event loop began.

In the past, a timer-specific low-level interface may have been desirable
from an implementation point of view. I don't believe this the case any
more, given two factors -- modern JS engines are really fast at this stuff,
and we are not going to be doing any kind of pre-emptive timer (so alarm()-,
setitimer()-, etc-backed implementations are unnecessary).

I really think if we're looking at setTimeout() we should be looking at
arbitrary condition evaluation in the event loop.  The embedders will be
able to fill in the blanks, and I bet most browser vendors are pretty much
already there.

Wes

-- 
Wesley W. Garland
Director, Product Development
PageMail, Inc.
+1 613 542 2787 x 102
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20110319/1a231187/attachment.html>