[whatwg] WebWorkers vs. Threads
shannon at arc.net.au
Sun Aug 10 17:54:18 PDT 2008
Jonas Sicking wrote:
> 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:
> 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.
> 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
I assumed setTimeout used real threads but I'm not advocating its use
anyway. I think Lua co-routines solve every issue you raise. I hope
WebWorkers will follow this model because I know from experience they
are very easy to use. The basic features are:
* each coroutine gets a real OS thread (if available).
* coroutines can access global variables; Lua handles the locking itself.
* yield and resume are available, but optional.
* coroutines are garbage-collected when complete.
* coroutines run a function, not a file. There is no need for a separate
the syntax is:
... do stuff ...
workerThread1 = coroutine.create( workerThreadFunction )
automatically skipping threads that are waiting on IO or blocked waiting
on user input since these actions usually represent a large faction of a
web page workload.
Maybe I misunderstand the concept of "shared nothing" but I think
denying access to global objects is unwise. Maybe in a low-level
language like C that's a bad thing but high-level languages can
serialise simultaneous access to variables to prevent crashes and
deadlocks. Performance can be improved by explicitly declaring private
thread variables using var.
If coroutines are adopted I hope they will be called "coroutines".
WebWorkers sounds silly and doesn't really assist in understanding their
purpose (you have to already know what they are to understand the analogy).
I think this proposal belongs in an ECMAScript discussion group but I
only bring it up here due to my extreme dislike of the current
WebWorkers proposal. I think the best way forward is to drop WebWorkers
completely from HTML5 and let the ECMAScript group look at it for JS 2.0
More information about the whatwg