[whatwg] WebWorkers vs. Threads
Jonas Sicking
jonas at sicking.cc
Sun Aug 10 10:37:06 PDT 2008
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
More information about the whatwg
mailing list