Why does the following JS function wreck the browser process?

Question

var wait = function (milliseconds) {
    var returnCondition = false;
    window.setTimeout(function () { returnCondition = true; }, milliseconds);
    while (!returnCondition) {};
};

I know there have been many posts already about why not to try to implement a wait() or sleep() function in Javascript. So this is not about making it usable for implementation purposes, but rather making it work for proof of concept's sake.

Trying

console.log("Starting...");wait(3000);console.log("...Done!");

freezes my browser. Why does wait() seemingly never end?

Edit: Thanks for the answers so far, I wasn't aware of the while loop never allowing for any other code to execute.

So would this work, then?

var wait = function (milliseconds) {
    var returnCondition = false;
    var setMyTimeOut = true;
    while (!returnCondition) {
        if (setMyTimeOut) {
            window.setTimeout(function() { returnCondition = true; }, milliseconds);
            setMyTimeOut = false;
        }
    };
    return;
};

Javascript is single threaded, and with your while loop you are blocking any other code from ever being executed ... that's mainly why — devnull69, May 12 '15 at 08:05
The timeout doesn't work while the thread is locked, it should look like [this](http://stackoverflow.com/questions/20967006/how-to-create-a-sleep-delay-in-nodejs-that-is-blocking#answer-20967216) instead. — adeneo, May 12 '15 at 08:06
Your need for a `wait()` function is unclear to me. You're almost certainly Doing It Wrong™ — Madara's Ghost, May 12 '15 at 08:06
@Amadan I don't mean his code. His code is obviously wrong and it's detailed in the answers. I'm talking about what he's trying to do. JavaScript is asynchronous, you shouldn't wait on synchronous things. — Madara's Ghost, May 12 '15 at 08:08
In response to edit: No, it would not work. Again, you are never setting `returnCondition` to `true` within the current execution path, so you are ending up with an infinite loop. It doesn't matter if you schedule the timeout from inside the loop or outside the loop; it will not execute until your script's last line is finished. — Amadan, May 12 '15 at 08:41
If you want to be evil, you can use a loop monitoring `new Date().getTime()` to create a nasty, blocking wait in a web page. But don't. — Mark K Cowan, Nov 21 '16 at 01:09

Amadan · Accepted Answer · 2015-05-12T08:42:18.650

JavaScript is executed in a single thread. Only when an execution path exits can another execution path begin. Thus, when you launch your wait(3000), the following happens:

returnCondition is set to false
a timeout is scheduled
an infinite loop is started.

Each <script> tag, each event being handled, and each timeout (and also UI refresh, in case of a browser) initiate a separate execution path. Thus, a timeout of 3000 is not guaranteed to run in 3000ms, but at any time after 3000ms when the engine is "free".

The wait function never exits, so your script's execution path never ends, and the scheduled timeout's turn never comes.

EDIT:

That means, once a <script> tag has begun, or Node.js has started executing a JavaScript file, the execution has to reach the bottom before anything else can happen. If a function is started as a result of an event or a timeout, that function needs to exit before anything else can happen.

<script>
  console.log("script top");
  function theTimeout() {
    console.log("timeout top");
    // something long
    console.log("timeout bottom");
  }
  setTimeout(theTimeout, 0);
  setTimeout(theTimeout, 0);
  console.log("script bottom");
</script>

There are three execution paths here. The first is the <script> tag's: it starts with printing "script top", schedules two timeouts (for "right now"), then prints "script bottom", and then the end of <script> is reached and the interpreter is idle. That means it has time to execute another execution path, and there are two timeouts is waiting, so it selects one of them and starts executing it. While it is executing, again nothing else can execute (even UI updates); the other timeout, even though it was also scheduled at "immediately", is left to wait till the first timeout's execution path ends. When it does, the second timeout's turn comes, and it gets executed as well.

I understand, at least partly. What if I set the timeout inside the while loop once? — connexo, May 12 '15 at 08:22
If you launched a timeout inside an infinite loop, you would just eat up memory remarkably quickly. I am not brave enough to try and see if Chrome would abort it really really quickly, or if my computer would melt down in a pathetic pile of disk swapping first. — Amadan, May 12 '15 at 08:34
So even if you call setTimeout inside the while loop, it's callback would still only be executed by the time the while loop ends? — connexo, May 12 '15 at 10:45
You are telling the browser that after 3 seconds it should execute your function when it is free. — Amadan, May 12 '15 at 12:18

Jeno Laszlo · Answer 2 · 2015-05-12T09:21:23.060

JavaScript is single threaded. When you call setTimeout the method you passed in as an argument is placed to the async call stack. It means the very next line of code in your block is executing immediately after the setTimeout call and the function you passed in as an argument will execute after your wait method exits.

Your while loop is waiting for a condition which will never happen while the wait function is running because the function which will set your flag will not run until the wait function is done.

The correct way to implement wait is:

var wait = function (milliseconds, onEnd) {

    window.setTimeout(function () { onEnd(); }, milliseconds);

};

wait(1000, function(){alert('hi')});

Here you pass in a callback function which will execute after the timeout.

If you have multiple async style calls you can use promises. Promises will make your code easy to read and it will be easy to chain multiple async calls together. There are very good promise librarians: JQuery has $.Deferred built into it but you can use Q if you are writing node.js code.

A promise style implementation would look something like this:

var wait = function (milliseconds) {

    var onEnd = null;

    window.setTimeout(function () { onEnd(); }, milliseconds);

    return {

    then: function(action){
            onEnd = action;
    }

    }
};

wait(1000).then(function(){alert('hi')});

https://api.jquery.com/jquery.deferred/ https://github.com/kriskowal/q

The following book helped me a lot to understand this subject:

Async JavaScript: Build More Responsive Apps with Less Code by Trevor Burnham https://pragprog.com/book/tbajs/async-javascript

Why does the following JS function wreck the browser process?

2 Answers2