By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
438,818 Members | 2,089 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 438,818 IT Pros & Developers. It's quick & easy.

setTimeOut and infinite recursion

P: n/a
As we know, Javascript suffers an insufferable lack of a wait() or
sleep() function, and so setTimeOut must step in to take up the slack.
A function can use setTimeOut like sleep() by calling itself after x
seconds. This begs a few questions: Is this design building enormous
calling stacks to nowhere? Will the users machine eventually run out of
memory space to contain this stack? How can this be avoided?

Thanks,

-- Whit Nelson

Sep 16 '06 #1
Share this Question
Share on Google+
9 Replies


P: n/a
pe**********@gmail.com wrote:
As we know, Javascript suffers an insufferable lack of a wait() or
sleep() function, and so setTimeOut must step in to take up the slack.
A function can use setTimeOut like sleep() by calling itself after x
seconds. This begs a few questions: Is this design building enormous
calling stacks to nowhere? Will the users machine eventually run out of
memory space to contain this stack? How can this be avoided?

Thanks,

-- Whit Nelson

There are a limited number of timers , so
if you use them all up , setTimeout() and setInterval() would
return null in lue of timer id's and do nothing.

If I intend to have a lot of "waiting" , I typically
use a single setInterval() function to pump a routine
that manages a timestamped collection of targets

This is what I do to support retries on multiple
concurrent transactions from javascript to my server backend
and beyond.
Sep 16 '06 #2

P: n/a
drclue <dr****@drclue.netwrote in news:ym0Pg.12585$bM.8435
@newsread4.news.pas.earthlink.net:
I typically
use a single setInterval() function to pump a routine
that manages a timestamped collection of targets
Interesting. Can you give us an example, or point to a page?
Sep 17 '06 #3

P: n/a
Hi,

Lee wrote:

<snip>
By the way, to "beg the question" doesn't mean what you think it means:
http://begthequestion.info/
So now it's official, there really is a webpage about *everything* ;-)

That was instructive!

Laurent
--
Laurent Bugnion, GalaSoft
Software engineering: http://www.galasoft-LB.ch
PhotoAlbum: http://www.galasoft-LB.ch/pictures
Support children in Calcutta: http://www.calcutta-espoir.ch
Sep 17 '06 #4

P: n/a
Jim Land wrote:
drclue <dr****@drclue.netwrote in news:ym0Pg.12585$bM.8435
@newsread4.news.pas.earthlink.net:
>I typically
use a single setInterval() function to pump a routine
that manages a timestamped collection of targets

Interesting. Can you give us an example, or point to a page?
Heres a simplified description with some pseudo code.

Basically you for each wait type event
create an object containing all the information to describe the time
period and the desired action in a self contained way.
perhaps like this.
var aMyWait=[]
var oMyWait={start:new Date().valueOf(),wait:700,szEval:"alert('hi')"}

Now take that oMyWait object, and stick it in an array

aMyWait[aMyWait.length]=oMyWait

now have a setInterval pumped function iterate
the array checking each oMyWait type object in your aMyWait array
and when the time has elapsed eval the expression and remove the
object from the array.

function throbber()
{
var x=0
var tTimeNow =new Date().valueOf();
// Scan for stale connections
for(x=0;x<aMyWait.length;x++)
{
var thisWait=aMyWait[x]
if(tTimeNow-thisWait.start>thisWait.start+thisWait.wait)
{
eval(thisWait.szEval)
aMyWait.splice(x,1)
}
}
}




Sep 17 '06 #5

P: n/a
drclue wrote:
[...]
There are a limited number of timers , so
if you use them all up , setTimeout() and setInterval() would
return null in lue of timer id's and do nothing.
What is the limit that you have discovered? There's no limit noted in
either Gecko or MSDN documentation. I tested setting concurrent
timeouts[1] in Firefox and IE - Firefox was happy up to 100,000[2] (and
probably beyond, my patience ran out), IE seems to get lost somewhere
between 60,000 and 70,000. You can set a much higher number
consecutively without any problems - both browsers were happy to set
500,000 consecutive timeouts in blocks of 10,000 set concurrently.

Firefox seems to allocate timer numbers sequentially from 1, IE uses
some other scheme that numbers timeouts around 2.7e7. There is a
simple test below - it will consume quite a bit CPU when running. You
can watch the memory use climb as more timers are set, then see it fall
as they are executed.

If you are setting in excess of say 10,000 timers concurrently there is
something seriously wrong with your application architecture (which is
probably true if you are setting more than about 10 concurrently). And
if you are setting more than 500,000 consecutively, you're probably
expecting to set one every few seconds over several weeks in which case
you need to look seriously at memory management (and whether JavaScript
is the right tool for the job).
<script type="text/javascript">

function emptyFn() {};

var lotsTimer, numRuns = 0;

function setLotsOfTimers( limit ){
++numRuns;
setTimers(limit);
lotsTimer = setTimeout('setLotsOfTimers(' + limit + ');',20000);
}

function setTimers( limit ){
msgString = 'Reached limit: ' + limit;
var msgEl = document.getElementById('xx');
while ( limit-- ){
var x = setTimeout('emptyFn();', 100);
if ('number' != typeof x){
msgEl.innerHTML = 'Didn\'t finish.<br>Last setTimeout: '
+ x + '<br>Runs: ' + numRuns;
if (lotsTimer) clearTimeout(lotsTimer);
return;
}
}
msgEl.innerHTML = msgString + '<br>Last setTimeout: '
+ x + '<br>Runs: ' + numRuns;
}
</script>
<form action="">
<input type="text" name="limit" value="10000">
<input type="button" value="Set timers"
onclick="setTimers( this.form.limit.value );">
<input type="button" value="Set lots..."
onclick="setLotsOfTimers(this.form.limit.value);">
<input type="button" value="Cancel lots"
onclick="if (lotsTimer){clearTimeout(lotsTimer);lotsTimer=null ;">
</form>
<div id="xx"></div>

1. "Concurrent" meaning all set within a loop so that all of them are
set before the first one runs

2. I think setting 100,000 concurrent timeouts in a javascript
application is absurd, it was done here purely to see if I could find a
limit. I think the practical limit is probably about 1,000 or less.
--
Rob

Sep 18 '06 #6

P: n/a
RobG wrote:
drclue wrote:
[...]
>There are a limited number of timers , so
if you use them all up , setTimeout() and setInterval() would
return null in lue of timer id's and do nothing.

2. I think setting 100,000 concurrent timeouts in a javascript
application is absurd, it was done here purely to see if I could find a
limit. I think the practical limit is probably about 1,000 or less.
Perhaps over time the limit has gone away, but at one time
I recall an 8 timer limit.

I think I'll keep with the setInterval and array approach
as it gives me a lot more bank for the buck, but none the less
it's a good thing to know that one can fill the browser with timers.
Thanks for the info!

Sep 18 '06 #7

P: n/a
JRS: In article <11**********************@i3g2000cwc.googlegroups. com>,
dated Sat, 16 Sep 2006 16:45:02 remote, seen in
news:comp.lang.javascript, pe**********@gmail.com posted :
>As we know, Javascript suffers an insufferable lack of a wait() or
sleep() function, and so setTimeOut must step in to take up the slack.
There is no need for wait() or sleep(), as setTimeout does all that is
required.
>A function can use setTimeOut like sleep() by calling itself after x
seconds. This begs a few questions: Is this design building enormous
calling stacks to nowhere?
Of course not. Each currently-waiting timer uses resource, that is all.
Will the users machine eventually run out of
memory space to contain this stack?
Therefore, no.
How can this be avoided?
It cannot be achieved in that fashion.
>-- Whit Nelson
Defective signature format.

--
John Stockton, Surrey, UK. REPLYyyww merlyn demon co uk Turnpike 4
Web <URL:http://www.uwasa.fi/~ts/http/tsfaq.html-Timo Salmi: Usenet Q&A.
Web <URL:http://www.merlyn.demon.co.uk/news-use.htm: about usage of News.
No Encoding. Quotes precede replies. Snip well. Write clearly. Mail no News.
Sep 19 '06 #8

P: n/a
JRS: In article <4l*****************@newsread4.news.pas.earthlink. net>,
dated Sun, 17 Sep 2006 18:19:44 remote, seen in
news:comp.lang.javascript, drclue <dr****@drclue.netposted :
>Heres a simplified description with some pseudo code.

Basically you for each wait type event
create an object containing all the information to describe the time
period and the desired action in a self contained way.
perhaps like this.
var aMyWait=[]
var oMyWait={start:new Date().valueOf(),wait:700,szEval:"alert('hi')"}
That seems inefficient. A timeout does not need to know when it
started, nor how long it is; it only needs to know how much longer to
wait. Don't repeat work unnecessarily.
>Now take that oMyWait object, and stick it in an array

aMyWait[aMyWait.length]=oMyWait

now have a setInterval pumped function iterate
the array checking each oMyWait type object in your aMyWait array
That is inefficient. Maintain the array in timeout order, and then only
the leading elements need be checked. Use insertion sort, since that
only needs a partial scan of the array at each insertion. Typically,
too, a long timeout will be inserted rarely, so the average insertion
scan will be shortish. (There may be even better ways.)
>and when the time has elapsed eval the expression and remove the
object from the array.
There will be no need for eval if instead a function name is in the
Object - just call the function. Another object element can be used to
provide a structure of parameters to the function. That may well be
quicker, and should not be significantly slower.

One should only use eval when it is useful to do so.
Rather than using setInterval, ISTM that one should, before starting the
"current" event(s), set a timeout that will run until the next loaded
event (insertion of a short interval during a long one will need to re-
schedule the event that was being waited for).

It's a good idea to read the newsgroup and its FAQ.
--
John Stockton, Surrey, UK. ?@merlyn.demon.co.uk Turnpike v4.00 IE 4
<URL:http://www.jibbering.com/faq/>? JL/RC: FAQ of news:comp.lang.javascript
<URL:http://www.merlyn.demon.co.uk/js-index.htmjscr maths, dates, sources.
<URL:http://www.merlyn.demon.co.uk/TP/BP/Delphi/jscr/&c, FAQ items, links.
Sep 19 '06 #9

P: n/a
Did you call my signature defective? I think your FACE is defective.

Sweet burn.

--------- RALPH waldO EM3rRson! +++++++

Dr John Stockton wrote:
JRS: In article <11**********************@i3g2000cwc.googlegroups. com>,
dated Sat, 16 Sep 2006 16:45:02 remote, seen in
news:comp.lang.javascript, pe**********@gmail.com posted :
As we know, Javascript suffers an insufferable lack of a wait() or
sleep() function, and so setTimeOut must step in to take up the slack.

There is no need for wait() or sleep(), as setTimeout does all that is
required.
A function can use setTimeOut like sleep() by calling itself after x
seconds. This begs a few questions: Is this design building enormous
calling stacks to nowhere?

Of course not. Each currently-waiting timer uses resource, that is all.
Will the users machine eventually run out of
memory space to contain this stack?

Therefore, no.
How can this be avoided?

It cannot be achieved in that fashion.
-- Whit Nelson

Defective signature format.

--
John Stockton, Surrey, UK. REPLYyyww merlyn demon co uk Turnpike4
Web <URL:http://www.uwasa.fi/~ts/http/tsfaq.html-Timo Salmi: Usenet Q&A.
Web <URL:http://www.merlyn.demon.co.uk/news-use.htm: about usage of News.
No Encoding. Quotes precede replies. Snip well. Write clearly. Mail no News.
Sep 24 '06 #10

This discussion thread is closed

Replies have been disabled for this discussion.