JavaScript Threading - Part 1 (Timers)

December 18, 2012 by JavaScript   Threading  

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). 

<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). 

<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. 

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.


Leave a Comment


Related Posts

JavaScript Threading - Part 2 (Worker)

December 18, 2012