Adding proper multi threading

The last couple of weeks I've been working on adding proper multi threading support in Ember. This builds on the work Manuel did during the 2009 Google Summer of Code.
Basically there are two goals with adding better multi threading:
1) Make Ember seamless, so there aren't any stuttering when large pieces of data is processed in the main thread.
2) Leverage the way modern CPUs today come with multiple cores, making the client faster overall.

The first goal is the most pressing. Since Ember is totally controlled from the server, and nothing about the world is known beforehand, situations often occur where as the user moves through the world new data is presented which requires extensive processing. The best example of this is the terrain and the way new terrain features are streamed to the user in real time.

When researching how best to implement multi threading two approaches presented themselves. Either I could devise a system where each subsystem had a dedicated thread, and then make sure that these subsystems communicated with each other in a safe way. Or I could try to identify smaller pieces of functionality which could be run in parallel and define tasks for these.
The first approach would solve the main issue, i.e. making sure that the main rendering thread works uninterrupted, but wouldn't help with the second goal. There's only so many subsystems to work with, and in some years time it won't be uncommon with 16+ cores. Instead I opted for the second approach, which is to try to identify "tasks" which then can be designed to be executed in separate threads. This approach puts more demand on the ability to identify tasks, and to design them so that the data they operate on is safely separated from other threads. But the benefit is that it's now possible to better utilize multiple cores.

For this purpose I've implemented a simple task execution framework in Ember. The first target of improved multi threading support using this framework has been the terrain system. Unfortunately our terrain library, Mercator, is not designed at all to allow multiple threads to access it, so currently I still have to make sure that only one thread at a time is interacting with Mercator. But this interaction now always happen in a thread separate from the rendering thread. As the terrain changes settle I'll be moving on to other parts of Ember which also will benefit from multi threading.