[whatwg] WebWorkers vs. Threads

Shannon wrote:
> I've been following the WebWorkers discussion for some time trying to 
> make sense of the problems it is trying to solve. I am starting to come 
> to the conclusion that it provides little not already provided by:
> 
> setTimeout(mainThreadFunc,1)
> setTimeout(workThreadFunc,2)
> setTimeout(workThreadFunc,2)

Web workers provide two things over the above:

1. It makes it easier for the developer to implement heavy complex 
algorithms while not hanging the browser.
2. It allows web pages to take advantage of multicore CPUs.

details:
What you describe above is also known as cooperative multithreading. 
I.e. each "thread" has to manually stop itself regularly and give 
control to the other threads, and eventually they must do the same and 
give control back.

However this means that you have to deep inside your threads algorithm 
return out to the main event loop. This can be complicated if you have a 
deep callstack with a lot of local variables holding a lot of state.

Thus 1. Threading is easier to implement using workers since you don't 
have to escape back out to the main event loop.

Also, web workers allow the browser to spin up real OS threads and put 
off the worker execution there. So if you have a multicore CPU, which is 
becoming very common today, the work the page is doing can take 
advantage of more cores, thus producing better throughput.

I'm also unsure which mozilla developer has come out against the idea of 
web workers. I do know that we absolutely don't want the "traditional" 
threading APIs that include locks, mutexes, synchronization, shared 
memory etc. But that's not what the current spec has. It is a much much 
simpler "shared nothing" API which already has a basic implementation in 
recent nightlies.

/ Jonas

Received on Sunday, 10 August 2008 10:37:06 UTC