On 1/8/11 4:07 AM, Jack Coulter wrote:
Sorry, I wasn't really clear. What I meant was, a private DOM hierarchy. You
still wouldn't be able to access it in multiple places simultaneously, and
you'd still have to serialise it to a string to use it in postMessage. Forgive
my ignorance, but if this were the case, then isn't the thread-safety issue
effectively sidestepped?
You're assuming that none of the DOM implementation code uses any sort
of non-DOM objects, ever, or that if it does those objects are fully
threadsafe. That's just not not the case, at least in Gecko.
The issue in this case is not the same DOM object being touched on
multiple threads. The issue is two DOM objects on different threads
both touching some global third object.
For example, the XML parser has to do some things that in Gecko can only
be done on the main thread (DTD loading, offhand; there are a few others
that I've seen before but don't recall offhand).
This would allow developers to parse and manipulate XML in workers, freeing
the main thread of a page to perform other tasks.
...
Why '...'? Did I say something in error here?
No, I was just indicating that I'd snipped some text there.
I know of E4X, and while I think it's a really nice language feature, the lack
non-gecko support makes it substantially less useful.
Well... so we're comparing a feature that's supported in Gecko but not
other UAs to a feature that's not supported in any UA, right? ;)
(Fwiw, I think the way E4X was actually done is insane; heck it
redefines what the |x.y()| syntax means! But perhaps some other API
along those lines that doesn't actually create DOM nodes with all their
weird behaviors (e.g. if you create an <img> it tries to load things off
the network) and instead just parses XML into objects exposed to JS
would be a better fit for workers.)
-Boris
