Why is Timer#schedule(0) bad?

[Ray Ryan]

Bob and I were just startled to see that you can't set schedule a timer to zero:

  /**

   * Schedules a timer to elapse in the future.

   * 

   * @param delayMillis how long to wait before the timer elapses, in

   *          milliseconds

   */

  public void schedule(int delayMillis) {

    if (delayMillis <= 0) {

      throw new IllegalArgumentException("must be positive");

    }

    ...

0 is JavaScript's convention for "do this in the next cycle of the event pump." Why are we preventing its use?

rjrjr

[Bruce Johnson]

I can't think of a good reason historically. IMO, it's a bug.

[John Tamplin]

On Mon, Dec 8, 2008 at 8:08 PM, Ray Ryan <rj...@google.com> wrote:

I think I remember something where one of the browsers did something different on 0.  Perhaps Joel or Kelly can confirm that.

--
John A. Tamplin
Software Engineer (GWT), Google

[Ray Cromwell]

I've always assumed that 0 wasn't portable and use 10 by convention.
Ideally, you'd want 0 to function like yield(), but I had a nagging
suspicious that some browsers might treat 0 as a NOP (that is, run the
code immediately without yielding)

[Bruce Johnson]

On Mon, Dec 8, 2008 at 8:34 PM, Ray Cromwell <cromw...@gmail.com> wrote:

I've always assumed that 0 wasn't portable and use 10 by convention.
Ideally, you'd want 0 to function like yield(), but I had a nagging
suspicious that some browsers might treat 0 as a NOP (that is, run the
code immediately without yielding)

Even so, the API method itself should accept 0, I think, and we could just round it up to the lowest number acceptable to the browser, such as "time = time <=0 ? 10 : time" or something like that.

[Kelly Norton]

Everone clamps timers now. Chrome launched without a clamp, but even
without the clamp setTimeout(..., 0) enqueued an event onto the
message loop. There were some old mozilla browsers that didn't yield
on setTimeout of 0, but you would probably have to look pretty deep in
the archives to find one. Unless things have changed since the last
time I looked into this, this is the roll call on timer clamping:

Chrome: 4ms (fairly recent change)
Safari (mac): 10ms
Safari (win): 15ms
Firefox: 15ms (or 10ms if flash is running)
IE: 15ms
Opera: I have no clue.

So, that's just a really long way of saying that there is no danger in
allowing 0 and technically it is a perfectly legal value ... it's just
not very useful.

/kel

--
If you received this communication by mistake, you are entitled to one
free ice cream cone on me. Simply print out this email including all
relevant SMTP headers and present them at my desk to claim your creamy
treat. We'll have a laugh at my emailing incompetence, and play a game
of ping pong. (offer may not be valid in all States).

[Thomas Broyer]

On 9 déc, 07:16, Kelly Norton <knor...@google.com> wrote:
>
> Chrome: 4ms (fairly recent change)
> Safari (mac): 10ms
> Safari (win): 15ms
> Firefox: 15ms (or 10ms if flash is running)
> IE: 15ms
> Opera: I have no clue.
>
> So, that's just a really long way of saying that there is no danger in
> allowing 0 and technically it is a perfectly legal value ... it's just
> not very useful.

I'd add FWIW that HTML5 (pending a split into a distinct spec) defines
setTimeout and setInterval as to "asynchronously wait timeout
milliseconds and then queue a task [...]"
http://www.whatwg.org/specs/web-apps/current-work/multipage/no.html#timers

[James Robinson]

WebKit treats a time of 0 as 'set the timer to the lowest legal value'.  I'm not aware of any browsers where it results in the code running inline, that seems like a clear browser bug if it was the case.  The actual value that it clamps to varies by browser and changes occasionally.

You can actually run into some trouble with a timeout value of 0.  This will always bind to the lowest possible value and can cause excessive CPU thrashing and laptop battery draining in some browsers.  See http://lists.macosforge.org/pipermail/webkit-dev/2008-October/005145.html and http://code.google.com/p/chromium/issues/detail?id=792.  Some apps seem to depend on a certain clamp value existing as well, although this shouldn't be a problem for GWT.

- James

On Mon, Dec 8, 2008 at 11:45 PM, Bruce Johnson <br...@google.com> wrote:

[Ray Cromwell]

Maybe a safe default is to clamp to the value of 1 vertical blanking
period @ 60hz, or 16ms. It appears that on some systems, the timers
are inherently keyed to this resolution anyway.

-Ray