Re: DOM Level 1 Becomes a W3C Recommendation

Claude Zervas wrote:

> Congratulations, but the spec says nothing about this. You are misreading
> my suggestion. I'm saying the *spec* should be clear about multithread DOM
> usage.
> Your implementation and mine may support multithreading but others may not.
> For example, implementations that use cursor cacheing in the NodeList to boost
> efficiency will most likely fail when two threads are traversing the list.

Sorry  I improperly related two threads that happened to talk about NodeList and
have the same title.

Addressing thread-safety could be a good hand-holding thing, I agree, but I don't
see it as much of a show-stopper, since I can probably synchronize more
efficiently and effectively at the application level than the underlying APIs
can.

DOM presents a complex-enough model that simply synchronizing the base calls
themselves does not guarantee that the threads will not see the DOM in an
intermediate state that is likely to be fatal to the application for a wide
variety of application reasons.  The node I am processing to may have moved or
replaced in or out of the hierarchy, etc.  I am not certain I like thread safety
at the DOM API level because it really needs to exist before that level so why
pay for it twice?

Or were you thinking of addressing thread-safety in some other way that you could
give an example of?  As long as you synchronize around the calls, calls from
different threads to the same NodeList will succeed the same as if it had been
called twice from the same thread, but perhaps you had something else in mind?
While moving to an iterator would a good hand-holding measure, I certainly don't
want to share iterators between threads.

Ray Whitmer
ray@imall.com

Received on Friday, 2 October 1998 16:47:33 UTC