Here's a situation presented to me in one of the interviews I had to face recently.
Suppose that you have a function CalculateSomethingAwesome that is CPU intensive (runs for a considerable amount of time lets say 4 mins). Then when that function is called the browser will block for that 4 minutes that the function will take to compete. Which mean that our user will not be able to do anything for 4 minutes in the browser, essentially hanging the browser for those 4 minutes.
If you are confused to why I would run such a intensive task - Imagine that you have a mapping application. The user can click on the map, pan around, zoom in etc. Now consider that the user needed the route between a couple of points on the map and that route had to be optimized in all sorts of ways. Surely that would take time to execute. So the user selects the points and clicks calculate route. If we were then trying to calculate this route in the routine way by calling a our CalculateSomethingAwesome function, we would see that the user now would not be able to pan the map around when the calculation was taking place.
So the question is how can we avoid blocking the UI when such a function needs to be called?
Some of the approaches that I suggested were using AJAX and shifting the intensive operation to server side or if you could use HTML5 web workers but the fellow did not want to do ajax nor did he want HTML5 support he said what if I had to do this using only IE5 :/
and I was stumped ..
But there should be a way right. So if you think about the problem, then the problem that we have is that any UI events raised are not getting a chance to execute and do stuff when our long running process is executing. That is the reason we say that the UI is blocked. What if there was some way of giving those UI events a chance to run? If somehow we could first break down the long running process into smaller chunks of work. Then dispatch the process of those chucks in a sequential manner in such a way that any UI events that happen during the processing of a particular chunk gets a chance to execute before the next chunk of work is dispatched for processing.
The way this can be accomplished is by using the JavaScript timing methods like setTimeout() and converting / dispatching the work chunks as timer events which now will get queued in the event chain and will be serviced as and when they are received. Which means that while one chunk is being processed if there is a click event it will be put into the event queue. When the chunk finishes it calls the next chunk using a set time out. now this call will initiate a timer event which will be put into the event queue. the even queue is poped and the next event is the mouse event which has already been queued earlier. The mouse event executes and then pops the event queue again which will execute the timer event which is our next chunk of work.
This was pretty mind blowing for me to understand. A pretty eloquent solution to mimicking concurrency in a single threaded environment. :) sort of reminded me of TDM :D
here's an interesting article that explains it a bit more and even gives some code examples of how this can be made into a generic pattern.
Sorry about the long winded blog post but I was just too excited about what I had learned :) .. imagine that these guys did this about 10 years ago in JavaScript .. its pretty darn impressive !!
You know how you start out to do something and end up learning something completely different. One of those rare moments happened yesterday. I had finally gotten fed up of the stupid login screen that my reliance broadband connection throws at me after every 20 minutes of inactivity. So based on something that my friend Mihir (
