[whatwg] WebWorkers vs. Threads

[Kristof Zelechovski]

A background task invoked by setTimeout has to be split to small chunks;
_yielding_ occurs when each chunk ends (having called setTimeout to execute
the next chunk).  It is very hard to code in this way; you have to maintain
an explicit stack and create an exit/entry point at every chunk boundary.
This technique is interesting as an academic exercise only, real-world
developers will be right to stay away from it.
It is not enough to _serialize_ access to global variables; you also have to
serialize access to anything accessible from them.  Example: 
{ var la = g.i; g.i = la + 1 }.  Run it twice in parallel and you will see
g.i incremented by 1 or 2, depending on the interleaving.  Is that what you
want?
Chris

-----Original Message-----
From: whatwg-bounces at lists.whatwg.org
[mailto:whatwg-bounces at lists.whatwg.org] On Behalf Of Shannon
Sent: Wednesday, August 13, 2008 10:14 AM
To: Jonas Sicking
Cc: WHAT working group
Subject: Re: [whatwg] WebWorkers vs. Threads

Jonas Sicking wrote:
> 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.

Actually I was referring to the browser forcefully interleaving the 
callback execution so they appear to run simultaneously. I was under the 
impression this is how they behave now. I don't see how Javascript 
callbacks can be cooperative since they have no yield statement or 
equivalent.

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

He wasn't against WebWorkers, he was, as you say,  against full 
threading (with all the mutexes and locks etc... exposed to the JS 
author). I can't find the reference site but it doesn't really matter 
except from the point of view that many people (including myself) aren't 
convinced a full pthread -like API is the way to go either. I just don't 
see why locking can't be transparently handled by the interpreter given 
that the language only interacts with true memory registers indirectly.