[whatwg] WebWorkers vs. Threads

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:
>>
>> 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
>

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 
file download.

the syntax is:

function workerThreadFunction()
   ... do stuff ...
end

workerThread1 = coroutine.create( workerThreadFunction )

A Javascript implementation could also assist the programmer by 
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 
or 3.0.

Shannon

Received on Sunday, 10 August 2008 17:54:18 UTC