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

Le 09/12/2009 14:53, Jonas Sicking a ?crit :
> On Wed, Dec 9, 2009 at 10:55 AM, Ian Hickson<ian at hixie.ch>  wrote:
>    
>> On Wed, 9 Dec 2009, David Bruant wrote:
>>      
>>> Ian wrote:
>>>        
>>>> 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.
>>>        
>> When I am referring to thread safety here I don't mean that it's not
>> possible for a single DOM tree to be accessed from two threads. I mean
>> that it's not possible for two DOM nodes from completely unrelated trees
>> to exist on two threads, because the DOM implementations make use of
>> global state (e.g. global atoms, memory pools) that are not written such
>> that they can be accessed from code in multiple threads (e.g. because the
>> memory allocator doesn't use locks to ensure that the memory pool is only
>> mutated by one thread at once).
>>      
> I can only speak for the gecko implementation, but what Ian says here
> is completely true.
>
> Behind the scenes there is lots of global data structures that we
> can't access from any other thread than the main thread. Thus we can't
> currently implement the DOM on any worker threads, even if any given
> node only ever lives on a single thread.
>
> We couldn't for example use the event dispatch code, or the
> XMLHttpRequest code directly in the worker thread. For events we
> basically duplicated the event dispatch code (or rather, we wrote
> another, much simpler, version to be used in workers). For
> XMLHttpRequest we end up proxying lots of information to the main
> thread where the majority of the code is run.
>
> / Jonas
>    
Thanks to your two answers, it makes sense now that breaking some 
references here and there didn't solve the problem.

I stop now my proposition.

Thank you for your feedback,

David

Received on Wednesday, 9 December 2009 16:29:47 UTC