Per the W3C spec, the DOM API does not promise to support multithread access. Doing so would impose performance/implementation limitations on all applications, even single-threaded ones, which was considered undesirable. Also, in most cases what you really need is threadsafety at a much higher level than single DOM operations.
In *some* (but not all) DOMs, you can get away with concurrent reads as long as nobody is altering the DOM. The Xerces "delayed DOM" is one which does _not_ promise to support that; if you tell Xerces to use the fully-preconstructed DOM implementation instead (do we still support it?) that may get you back on the air... but this is an implementation-specific hack and is not really good coding practice. It's better to put explicit thread handshaking into your application code where needed, via the use of appropriate semaphores and locks. ______________________________________ "... Three things see no end: A loop with exit code done wrong, A semaphore untested, And the change that comes along. ..." -- "Threes" Rev 1.1 - Duane Elms / Leslie Fish (http://www.ovff.org/pegasus/songs/threes-rev-11.html)
