[whatwg] WebWorkers vs. Threads

[Jonas Sicking]

Shannon wrote:
> 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.

One problem with what you're proposing is that in a browser environment 
the C host language and the javascript language is heavily intertwined. 
What do you do if a co-routine that lives in a separate thread calls 
into the DOM, which in most (all?) browser implementations isn't 
threadsafe? And what if that DOM call results in callbacks into 
javascript again?

/ Jonas