Re: Limited DOM in Web Workers

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

Received on Saturday, 8 January 2011 23:43:20 UTC