[whatwg] providing a DOM API to workers without a thread-safe DOM implementation

> On Mon, 7 Dec 2009, David Bruant wrote:
>    
>>> Plus, since browsers don't have thread-safe DOM implementations, we
>>> actually can't expose the DOM in workers. Maybe one day. :-)
>>>        
>> I'm sorry for the misunderstanding. I shouldn't have said "the DOM API".
>> To be as accurate as I can be I want to provide the DOMImplementation
>> interface (http://www.w3.org/TR/DOM-Level-3-Core/core.html#ID-102161490)
>> to the workers. As I'm going to explain, the point is to be able to
>> create a document and then a documentFragment.
>>      
> Since browsers don't have thread-safe DOM implementations, that's
> basically a non-starter. It doesn't matter that we aren't offering access
> to the same DOM in pages and workers; the actual innards of the DOM
> implementations aren't thread safe.
>
> As soon as browsers are able to implement this, I'm sure it will be added
> to the spec.
>    
=> The point of my "Re: [whatwg] [WebWorkers] Advocation to provide the 
DOM API to the workers" e-mail of the December 7th was to prove that we 
don't even need a thread-safe implementation.

The requirement is just to have 2 implementations (which can be the 
same, but it would be a "coincidence") one for the main browsing 
context, the other for workers. Then, I'm describing a way to 
communicate (through postMessage and the onmessage handler) which allow 
to send and recieve DOM objects (Node/Element/Document/DocumentFragment) 
in a safe way (basically, by breaking the references to DOM objects 
coming from another implementation and I think that I have enumerated 
all of them and found a proper solution for each).

I think that what I describe can be implemented without a thread-safe 
implementation (so, it could be already implemented today).

David

Received on Wednesday, 9 December 2009 10:46:20 UTC