The thing I had in mind is that sometimes that's exactly what scripts do, they are so busy that they freeze that browser for a part of a second or two. For performance experiments that's what I wanted to simulate: a very busy script that locks the browser.

I don't think setTimeout will simulate exactly that. As Stuart shows above, if you use setTimeout() with even 0 milliseconds delay, this tells the browser: "finish what're doing and when you have a chance, execute what I've set with a timeout". In Stuart's example the two dates are logged (part of the current thread) and the sleep happens right after that.

Just use setTimeout.

If you really want a sleep function then try "Narative JavaScript" here: http://www.neilmix.com/narrativejs/doc/index.html. It's a pre-proccessor that allows you to use blocking code that it then changes to async code for you.

function sleep(milliseconds) {
var start = new Date().getTime();
while ((new Date().getTime() - start) < milliseconds){
// Do nothing
}
}

Tue Mar 25 2008 08:36:54 GMT+0000 (BST)
Tue Mar 25 2008 08:36:59 GMT+0000 (BST)

I'm thinking a non-blocking solution could look like this:

function sleep(milliseconds) {
setTimeout(function(){
var start = new Date().getTime();
while ((new Date().getTime() - start) < milliseconds){
// Do nothing
}
},0);
}

console.log(new Date());
sleep(5000);
console.log(new Date());

The script returns after the sleep but the second logged date is the same as the first:

Tue Mar 25 2008 08:34:51 GMT+0000 (BST)
Tue Mar 25 2008 08:34:51 GMT+0000 (BST)