Possible wrong assumption about setInterval #68

Closed
marcelkorpel opened this Issue Mar 27, 2011 · 6 comments

Projects

None yet

6 participants

@marcelkorpel

In setTimeout and setInterval (section 'Stacking Calls with setInterval') you write

When code that is being executed blocks the timeout call, setInterval will still issue more calls to the specified function. This can, especially with small intervals, result in function calls stacking up.

According to this answer on Stackoverflow.com, this is not correct:

But, they don't queue one on top of each other: there can only ever be one execution pending per interval. (If they all queued up, the browser would be left with an ever-expanding list of outstanding executions!)

(see mentioned answer for a graphical explanation)

@sanshi
Collaborator
sanshi commented Mar 27, 2011

Yes, I think the Stackoverflow's description is more precisely.

I have created an example to simulate the long response loop here: http://jsfiddle.net/sanshi/3XLHc/

@marcelkorpel

Yup, thanks for creating an example, I couldn't think of one within a few moments.

The result is (about) the same in Firefox 4.0, Chromium 10.0.648.151 and Opera 11.01, all running on Linux.

@michaelficarra

Looks like they queue up to me.

time:3s - count:1
time:5s - count:2
time:7s - count:3
time:10s - count:4
time:12s - count:5
time:14s - count:6
time:14s - count:7
time:15s - count:8
time:16s - count:9
time:17s - count:10

And MDC agrees. Either way, JS garden shouldn't be making claims about its functionality if it's not standardized.

@marcelkorpel

No, otherwise you'd see that the stacked up calls to loop would fire immediately one after the other after the first five calls (where the JS engine is bluntly kept busy), like:

time:3s - count:1
time:5s - count:2
time:7s - count:3
time:10s - count:4
time:12s - count:5
time:12s - count:6
time:12s - count:7
time:12s - count:8
time:12s - count:9
time:12s - count:10

Instead, after the first five calls there's only one call each second.

The warning in the MDC article is aimed at multiple, consecutive, asynchronous XMLHttpRequests: you never know when one ends and if you fire multiple requests, you'll never know which one is completed first, second, and so on.

If you want to continuously poll a server, you want the callback handlers be executed one after another, otherwise, for instance, messages in a chat system might appear in a wrong order. Using setTimeout, you can guarantee that on request is finished before a new one is fired.

@ZhangYiJiang ZhangYiJiang reopened this Mar 28, 2011
@sanshi
Collaborator
sanshi commented Apr 7, 2011

Yes, the description is not correct in en version. I will update Chinese translation later.
I have written a article discussing this issue (In Chinese): http://www.cnblogs.com/sanshi/archive/2011/03/28/1997348.html

My result:

time:4s - count:1
time:7s - count:2
time:10s - count:3
time:13s - count:4
time:16s - count:5
time:19s - count:6
time:19s - count:7
time:20s - count:8
time:21s - count:9
time:22s - count:10
time:23s - count:11
time:24s - count:12
time:25s - count:13
time:26s - count:14
time:27s - count:15
@ZhangYiJiang
Collaborator

#75 was marked a dupe of this

@ZhangYiJiang ZhangYiJiang reopened this Sep 25, 2011
@BonsaiDen BonsaiDen was assigned Sep 25, 2011
@timruffles timruffles closed this Apr 30, 2014
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment