W3C home > Mailing lists > Public > www-dom@w3.org > April to June 2001

Re: Node synchronization [was RE: Node identity comparisons on TS lis t]

From: Joseph Kesselman <keshlam@us.ibm.com>
Date: Fri, 20 Apr 2001 16:12:25 -0400
To: "Fred L. Drake, Jr." <fdrake@acm.org>
Cc: "Arnold, Curt" <Curt.Arnold@hyprotech.com>, "'www-dom-ts@w3.org'" <www-dom-ts@w3.org>, "'www-dom@w3.org'" <www-dom@w3.org>
Message-ID: <OFDEFB2401.3619DBED-ON85256A34.006D91F9@pok.ibm.com>

> I'll chime in to note that the DOM currently does not (as far as I
> can tell) have anything to say about concurrency.

In the intro, "DOM Level 2 does not specify multithreading mechanisms." And
DOM Level 1 listed threadsafety as an issue deferred to later levels.


Every time the DOM has looked at the idea of requiring that implementations
be inherently threadsafe, we seem to come back to the same conclusions.
This can be a lot of overhead in applications which don't need it, and is
insufficient in applications which do need it since the conceptual unit is
often several DOM operations so they'd still have to implement threadsafety
at the higher level... which would make protecting the DOM itself of
negligable value.

However, it's still on our open issues list as something to consider. As is
the possiblity of simply being able to "lock" the whole DOM (claim
ownership of it for an extended period and hold off other users until
ownership is explicitly released), which is probably a more useful
operation but which still seems to involve a lot of overhead for
applications which don't need this protection.

If someone can find a Really Useful Low Cost Portable Solution in this
space, I'd be delighted. Suprised, but delighted. Until then, you'll have
to handle threadsafety at the application or implementation-dependent
level.

______________________________________
Joe Kesselman  / IBM Research
Received on Friday, 20 April 2001 16:13:06 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 22 June 2012 06:13:48 GMT