Bringing setTimeout to ECMAScript

David Bruant david.bruant at labri.fr
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 >= Date.now() + 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
disappear.
Anyway, another "sufficiently long running algorithm" could loop and
exit the loop with a condition on a time difference measured with Date.now()

> 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
Date.now() 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.

David


More information about the es-discuss mailing list