[whatwg] WebWorkers vs. Threads

[Robert O'Callahan]

On Fri, Aug 15, 2008 at 7:54 AM, Maksim Orlovich <mo85 at cornell.edu> wrote:

> It's actually a lot worse in this case, since the ECMAScript runtime must
> be able to enforce the sandbox properly even in face of incorrectly
> threaded programs.
> In particular, if two threads are accessing properties of the same object
> at the same time w/o proper locking, the invariants of the property map
> data structure should not be violated, which means perhaps the most basic
> and hottest data structure in the language runtime has to be thread-safe
> (or, at the very least guarantee that whatever happens won't result in a
> crash). This is a heavy burden both on the performance and complexity of
> the implementation.  And, actually, all of the above would apply to
> concurrent DOM calls, too.
>

That is a very good point in general; defining and enforcing language
semantics in the presence of data races is very hard. Just check out the
"Java memory model" work.

For JS in particular, though, it's possible to be fast and thread-safe ---
Spidermonkey is. I'm not saying it's a good idea :-).

In contrast, a worker implementation, as far I can see, just requires
> thread safety of the message passing implementation --- hardly a
> challenge; and somewhat trickier but more localized safety of the GC heap.
>

AFAIK the workers use logically separate heaps, so the implementation can
physically separate the heaps if necessary.

Rob
-- 
"He was pierced for our transgressions, he was crushed for our iniquities;
the punishment that brought us peace was upon him, and by his wounds we are
healed. We all, like sheep, have gone astray, each of us has turned to his
own way; and the LORD has laid on him the iniquity of us all." [Isaiah
53:5-6]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20080815/c5c875aa/attachment-0001.htm>