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

[Jonas Sicking]

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