Bringing setTimeout to ECMAScript

David Bruant david.bruant at
Sun Mar 20 10:19:06 PDT 2011

Le 20/03/2011 17:14, Kyle Simpson a écrit :
>>> I don't see why "you can't verify your expectation".
>> If you think you can verify your expectation, please write ECMAScript
>> interoperable test cases that show how to test whether an ECMAScript
>> engine is conform to your scheduling policy or not. It will be enough to
>> convince me.
>> Testing one timer ("When you do a setTimeout( f, ms ) you know you are
>> saying "fire this @ t >= + ms" ") will not be difficult.
>> Testing your scheduling policy is a different story.
> Forgive my naivety, but would it not be possible to test such a
> scheduling policy with something like this:
> var test = 1;
> function a() {
>   test *= -1;
> }
> function b() {
>   assertEquals(test,-1);
> }
> setTimeout(a,0);
> for(i=0;i<1E10;i++){i=i;}  // or any other sufficiently long running
> algorithm
Actually, a dead code elimination optimization would make the loop
Anyway, another "sufficiently long running algorithm" could loop and
exit the loop with a condition on a time difference measured with

> setTimeout(b,0);
I agree that some properties of a scheduling policy can be tested (like
you can test that times moves forward with two sequential calls to or testing statistical properties of Math.rand()) but there
is something in the time that code uses to execute that is inherently
non-determinist (the dead code elimination optimization is actually an
excellent proof of this). This cannot be avoided in my opinion, making
scheduling policy non-testable, not verifyable and hence non-relyable.


More information about the es-discuss mailing list