CODEWITHSUNDEEP
javascriptrecursion
pm100
pm100

Reputation: 50190

Is this recursion or not

function x(){
  window.setTimeout(function(){
     foo();
     if(notDone()){ 
        x();
     };
  },1000);
}

My concern being unbounded stack growth. I think this is not recursion since the x() call in the timer results in a brand new set of stack frames based on a new dispatch in the JS engine.

But reading the code as an old-fashioned non JS guy it makes me feel uneasy

One extra side question, what happens if I scheduled something (based on math rather than a literal) that resulted in no delay. Would that execute in place or would it be in immediately executed async, or is that implementation defined

Upvotes: 11

Views: 689

Answers (4)

Andrew Faulkner
Andrew Faulkner

Reputation: 3930

Recursion has many different definitions, but if we define it as the willful (as opposed to bug-induced) use of a function that calls itself repeatedly in order to solve a programming problem (which seems to be a common one in a Javascript context), it absolutely is.

The real question is whether or not this could crash the browser. The answer is no in my experience...at least not on Firefox or Chrome. Whether good practice or not, what you've got there is a pretty common Javascript pattern, used in a lot of semi-real-time web applications. Notably, Twitter used to do something very similar to provide users with semi-real-time feed updates (I doubt they still do it now that they're using a Node server).

Also, out of curiously I ran your script with the schedule reset to run every 50ms, and have experienced no slowdowns.

Upvotes: 0

Alnitak
Alnitak

Reputation: 339846

It's not - I call it "pseudo-recursion".

The rationale is that it kind of looks like recursion, except that the function always correctly terminates immediately, hence unwinding the stack. It's then the JS event loop that triggers the next invocation.

Upvotes: 4

pllee
pllee

Reputation: 3959

It is recusive in a sense that it is a function that calls itself but I believe you are right about the stack trace being gone. Under normal execution the stack will just show that it was invoked by setTimeout. The chrome debugger for example will allow you to keep stack traces on async execution, I am not sure how they are doing it but the engine can keep track of the stack somehow.

No matter how the literal is calculated the execution will still be async.

setTimeout(function(){console.log('timeout');}, 0);console.log('executing');

will output:

executing
undefined
timeout

Upvotes: 2

Platinum Azure
Platinum Azure

Reputation: 46193

One extra side question, what happens if I scheduled something (based on math rather than a literal) that resulted in no delay. Would that execute in place or would it be in immediately executed async, or is that implementation defined

Still asynchronous. It's just that the timer will be processed immediately once the function returns and the JavaScript engine can process events on the event loop.

Upvotes: 1

Related Questions