We Keep Coding

Do NodeJS setInterval()s queue up?

There's a classical problem with setInterval() in browsers - if some JS code or other browser process takes too long to complete, several callback invocations might get "backed up" and you suddenly end with your callback executed multiple times in quick succession.
Often this is not what is desired when setInterval() is used. It's a typical use case when you want AT LEAST some interval of time to pass between invocations. The workaround to this is to use setTimeout() instead and only schedule the next invocation when the previous is completed.
This works well but also is extra code and might be confusing for someone who does not understand the issue.
I know that NodeJS works differently than browsers, but I cannot find any information on this particular aspect. Does NodeJS also exhibit the same behavior, or does it guarantee a minimum time between invocations when using setInterval()?

Looks like it.
start = () => {
console.log(Date.now(), 'interval started');
setInterval(() => console.log(Date.now(), '-'), 1000);
}
busy = (n) => {
console.log(Date.now(), 'busy started');
for (let i = 1; i < n; i++) Math.sqrt(i, 7);
console.log(Date.now(), 'busy done');
}
start();
busy(1e10); // this takes a while; nothing is printed, because this keeps the node.js thread busy
Output:
1642469880773 interval started
1642469880776 busy started
1642469888272 busy done
1642469888272 -
1642469889273 -
1642469890274 -
Note the long gap between busy start and done, and how no backlog of interval callbacks seem to follow.

True thread blocking in javascript

Background:
The following code demonstrates that the alert function blocks the operation of setTimeout:
// clock time
function now(){ return (new Date()).getTime() }
var start = now(),
elapsed_before_interruption
// This will interrupt the function below
setTimeout(function(){
elapsed_before_interruption = now()-start
alert('Paused')
start = now()
}, 2000)
setTimeout(function(){
var elapsed_since_interruption = now() - start
var elapsed = elapsed_since_interruption + elapsed_before_interruption
// drop < 1/100s from display
var t = Math.round(100 * elapsed / 1000)/ 100
// Always finishes ~4 seconds after (i.e has been interrupted)
alert( 'Elapsed time: ' + t 's' )
}, 4000)
fiddle
This makes for an excellent pause mechanism when I am choreographing various function calls based upon predetermined intervals.
My question:
Can this be done without calling alert?
EDIT
Whilst similar to the following question: What is the JavaScript version of sleep()? the responses to that question predominantly make the assumption that the OP is dealing with a scheduling issue and suggest code restructuring. I would like to keep this question up as I am specifically not asking for advice on working with promises etc.
By means of explanation, I am writing single web pages (only my code) that are used to conduct timed response latency trials. There are many moving parts and I can implement pause by simply writing
function pause(){ alert('paused') }
I however have to introduce the ugly browser dialog. Anyway to avoid this?

The very short answer: Don't do it this way. If you need to control the order of async processes, there are a variety of better ways.
For debugging, use the Chrome dev tools to set a breakpoint. Much easier.
If you want to wait for something specific, approaches like Promises, callbacks, and libraries like async or queue are relatively easy to use and more flexible.
If you want the syntactical simplicity of waiting in the middle of a function, try precompiling your code with babel and using the async/await syntax, which behaves in a similar way to what you have here (though you need to wait for something specific).
Note that none of these are "true thread blocking". There's only one thread in JS (unless you're using Workers or similar); you can block it with something like while(true) {}, but it locks everything in your browser window, including user interactions. You don't actually want that.

Understanding async using setTimeout

I have a UI where I need animations to run smoothly. Every so often, I need to do a semi-large data calculation that makes the animation skip until it is this calculation is completed.
I am trying to get around this by making the data calculation async with setTimeout. Something like setTimeout(calcData(), 0);
The whole code is something like this (simplified):
while (animating) {
performAnimation();
if (needCalc) {
setTimeout(calcData(), 0);
}
}
But I still get a skip in the animation. It runs smoothly when I do not need to do any data calculations. How can I do this effectively? Thanks!

You are seeing the skip because only one javascript thread is run at once. When something is done asynchronously the javascript engine puts it a queue to be ran later, then finds something else to execute. When something in the queue needs to be done the engine will pull it out and execute it, blocking all other operations until it completes.The engine then pulls something else out of its queue to execute.
So if you want to allow your render to run smoothly you must break up your calculation into multiple async calls, allowing the engine to schedule the render operation in between calculations. This is easy to accomplish if you are just iterating over a array, so you can do something like:
var now=Date.now;
if(window.performance&&performance.now){//use performace.now if we can
now=performance.now;
}
function calculate(){
var batchSize=10;//If you have a exceptionally long operation you may want to make this lower.
var i=0;
var next=function(){
var start=now();
while(now()-start<14){//14ms / frame
var end=Math.min(i+batchSize,data.length);
for(;i<end;i++){//do batches to reduce time overhead
do_calc(data[i]);
}
}
if(i<data.length) setTimeout(next,1)//defer to next tick
};
next();
}
calculate();
function render(){
do_render_stuff();
if(animating) {
requestAnimationFrame(render);//use requestAnimationFrame rather then setTimeout for rendering
}
}
render();
Better yet, if you can, you should use WebWorkers which work in a different thread, completely separate from the main js engine. However you are stuck with this if you need to do something you cant do in a WebWorker, such as manipulating the DOM tree.

Firstly, let's talk what's going on in your code:
while (animating) {
performAnimation();
if (needCalc) {
// it should be setTimeout(calcData, 0);
setTimeout(calcData(), 0);
}
}
In line setTimeout(calcData(), 0); really you don't defer calling of calcData function, you call it, because you use () operator after function name.
Secondly, lets think, what's going on when you really make defer calling for calcData in the code above: commonly JavaScript is running in one thread, so, if you have code like this:
setTimeout(doSomething, 0);
while (true) {};
doSomething will never be called, because interpreter of javascript executes while loop forever and it hasn't "free time" to execute other things (even UI) . setTimeout - just say to schedule execution of doSomething when interpreter will be free and it's time to execute this function.
So, when browser executes javascript function, all other stuff become freezing.
Solution:
If you have big data that you need to process, maybe it would be better to make calculations on backend and after send results to frontend.
Usually when you need to make some calculation and render results it's better to use requestAnimationFrame than while loop. Browser will execute function passed in requestAnimationFrame as soon as possible, but also you give browser a time to handle other events. You can see smooth redrawing using requestAnimationFrame for game (step-by-step tutorial here).
If you really want to process huge amount of data at frontend part and you want to make ui works smooth, you can try to use WebWorkers. WebWorkers look like threads in JavaScript, you need to communicate between main UI "thread" and WebWorker by passing messages from one to another and back and calculations on WebWorker don't affect UI thread.

Mostly, your problem boils down to your incorrect usage of setTimeout()
setTimeout(calcData(), 0);
The first argument to setTimeout is a REFERENCE to the function that you wish to call. In your code, you are not referencing the calcData function, you are invoking it because you've included () after the function name.
Second, the fact that you've put 0 for the delay does not mean you will have a 0 second delay before the function runs. JavaScript runs in a single threaded context. The setTimeout function is placed in a queue and executed when the JavaScript engine is available, but no sooner than a minimum of 10ms or the amount you specify (whichever is less).
Realistically, your line should be:
setTimeout(calcData(),10);

For loops are disturbing rendering

I have some pretty simple 3D objects (basically THREE.Sphere which is a parent of 1-30 other THREE.Spheres, with RGB color and no texture) to display in somewhat real time animation.
The rendering is done in no time indeed, but I have some simple iterative calculation (for-loops) that are disturbing my display capabilities.
The rendering itself is not the problem, but the computation for the next frame vertices is what causing the pain
Meaning, when I just run the script, I can see that the for-loops are taking too much time to compute, and just then it goes to the rendering section which is done in no time.
I was thinking of dealing with this problem in a parallel computing manner- running a thread (worker, whatever it is called in JS) that would calculate the for-loop, but I thought that considering my lack of experience in computer graphocs, perhaps there is a more "graphic"ed way of doing so. Meaning a more elegant/performance-improved/natural way of dealing with such a fundamental problem of computer graphics design.

This is the basic idea I am using to do long slow calculations that don't get caught by the watchdog timers and bog down the browser or the render rate.
The basic idea is that you use a javascript generator that allows you to yield in the middle of a computation, and continue later on. Then, I run the generator pump on a timeout chain.
The key to this method is the "yield" operator that saves the function state and returns awaiting a future call to the .next() function. (btw this demo code might have to be re arraged to handle firefoxs forward references)
//function Chain represents the slow code
function *Chain()
{
for(i=0;i<1000000;i++) //this represents a long slow calculation
{
if(i%100==0) //on occassion, yield
yield;
}
}
console.log("starting chain");
gChain=Chain(); //startup and get the next generator pointer
timeout = setTimeout(function () { ChainStart(); }, 1);
//function ChainStart is a pump that runs the generator using a timeout chain so other threads can run
function ChainStart(){
if(gChain.next().done){
clearTimeout(timeout);
console.log("endingchain");
}
else{
clearTimeout(timeout);
timeout = setTimeout(function () { ChainStart(); }, 1);
}
}

Combined delayed function calls in Javascript

I am not quite sure what the technical term for this is. I have a GUI with interactive graphics. After the user has interacted with the GUI, I need to perform some CPU intensive action. However, user input is very frequent, so I only want to call the function after e.g. 1000ms of no userinput. Below the pattern that I use:
scheduler = (function(){
var timer;
function exec(call, delay){
clearTimeout(timer);
timer = setTimeout(call, delay);
};
return exec;
})()
I.e. if the 3 calls to scheduler are done right after each other, only the final one will actually be executed:
scheduler(function(){alert('foo')}, 1000);
scheduler(function(){alert('bar')}, 1000);
scheduler(function(){alert('zoo')}, 1000);
It seems to work, but it feels a bit hacky I am a little worried about any caveats of Javascript setTimeout, especially the scoping problems. Does this seem like a reliable pattern I could use on a larger scale? Will the inline function that I pass to scheduler be able to lookup all objects in its lexical scope as usual, when it is called by settimeout? What about if I have several of these scheduler instances? Could they interfere with each other? Is there an alternative way of accomplishing this?

You could opt for using web worker threads instead:
https://developer.mozilla.org/en-US/docs/DOM/Using_web_workers
http://www.html5rocks.com/en/tutorials/workers/basics/

What I would do:
http://jsfiddle.net/gunderson/4XXQ4/1/
var severQueue = [];
var delay;
$("#inputSquare").mousemove(onMouseMove);
function onMouseMove(){
if (delay){
clearTimeout(delay);
}
serverQueue.push("doSomething")
delay = setTimeout(sendToServer, 1000);
}
function sendToServer(){
console.log(serverQueue.length);
delay = null;
$("#inputSquare").addClass("activated");
// do some ajax using serverQueue
// we'll just simulate it with another timeout
for (var i in serverQueue){
serverQueue.pop();
}
onComplete = setTimeout(onAjaxComplete, 1000);
}
function onAjaxComplete(){
$("#inputSquare").removeClass("activated");
}
​

In theory, your solution looks like it will work. There are no scoping problems related to you passing a callback function to your scheduler function; the callback will close over whatever environment it was created in, just like any other function in JavaScript. That being said, scoping rules can be a bit tricky in JavaScript, so make sure that you read up on it.
In practice, there may be some browser-specific issues related to setTimeout that may make this solution unworkable. For example, the frequency at which certain browsers execute setTimeout callbacks may vary such that you'll be waiting longer than you expect for a callback to be executed. All setTimeout callbacks will be executed sequentially; they'll never be executed in parallel. However, you have guarantees as to what order they will be executed in.
All that being said, any major gotcha in your solution will likely have more to do with the callbacks that your registering rather than the way in which you're registering them.

The debounce function in underscore.js does exactly this:
debounce _.debounce(function, wait, [immediate])
Creates and returns a new debounced version of the passed function that will postpone its execution until after wait milliseconds have
elapsed since the last time it was invoked. Useful for implementing
behavior that should only happen after the input has stopped arriving.
For example: rendering a preview of a Markdown comment, recalculating
a layout after the window has stopped being resized, and so on.