- 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>
> 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 UTC