[whatwg] WebWorkers vs. Threads

[Shannon]

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