JavaScript Threading - Part 1 (Timers)
In the first part of this series we're going to have a look at timers
(setTimeout and setInterval functions).
Technically these functions are actually pseudo-threaded
(looks like a dog, smells like a dog, barks like a
dog, humps like a dog, not a dog) - they don't spawn new threads, but instead they cleverly get executed/queued on
a single thread
(along with other asynchronous events).
The first function we're going to look at is the setInterval function. This function accepts three arguments, of which
the first one is a callback, the second an interval
(in milliseconds) of when the callback will be executed.
The third argument is optional and sets the language
(of the callback script I guess ?) - I've personally never used this argument,
and can't see why any sane person would want to, can somebody enlighten us ?
My guess is it's got something to do with the client-side vbscript days, allowing one to
mix vbscript and JavaScript in Internet Explorer (puuuuukkkke) ?
In the following snippet we use the setInterval function to display the current time and update it every second
(a basic time
ticker).
Snippet 1
<div id="currentTime"></div>
<script type="text/javascript">
var timer = setInterval(
function()
{
var time = new Date().toLocaleTimeString();
$('#currentTime').html(time); // assuming you're using jQuery
}, 1000
);
</script>
Note that the value returned by this function can be used to stop the timer using the clearInterval function,
e.g. "clearInterval(timer)".
It's also prudent to point out that our callback will automatically get re-executed irrespective of when/if the previous
callback finished executing, so take care when putting code in your callback that can potentially exceed your interval,
which brings me to our next timer function - setTimeout.
The setTimeout function has the exact same arguments as the setInterval function, the only difference however is that
this function doesn't automatically continuously call its callback - which gives us a bit more control over our timer.
In the following snippet we use the setTimeout function to populate a div on our page via an ajax request
(using jQuery).
Snippet 2
<div id="results"></div>
<script type="text/javascript">
function GetResults()
{
var timeout = 1000; // 1 second
$.ajax(
{
url: 'http://cstruter.localhost/tests/timers/results.php',
cache: false
}
).done(function(data) {
$('#results').html(data);
setTimeout(GetResults, timeout); // only call the function again once we're done
}).fail(function(jqXHR, textStatus, errorThrown) {
if (confirm("Error sending request, try again?")) {
setTimeout(GetResults, timeout); // try call the function again
}
});
}
GetResults();
</script>
You'll notice that we only set our delayed callback as soon as we had a succesful response back from
our server, when something goes wrong with our response, we prompt the user to try again.
Note that like the setInterval function, we've got a function to stop our setTimeout as well - clearTimeout.
Now in the beginning of this post I mentioned that these functions are actually pseudo-threaded in that it
runs on the same thread. To demonstrate the problem with this
(from a threading perspective) you need to run the
following snippet along with snippet 1.
Snippet 3
setInterval(
function ()
{
var j = 0;
for (var i = 0; i < 1000000000; i++) { j++; } // simulate some intensive work
}, 1000);
You will notice that now instead of getting a nice smooth time ticker, the ticker starts to lag behind a bit, skipping
seconds. Which is obviously not the ideal behavior we're looking for but obvious seeing that we're doing everything on
one thread.
Wouldn't it be nice if we could put the problem function in its own isolated thread? Leaving the UI thread open for
all things UI?
In the next part we're going to have a look at doing exactly that using web workers.
Posted by - Christoff Truter
Date - 2012-12-18 08:40:27
Post comment