Re: [xml] libxml2 thread safety

On Tue, 2 Oct 2001, Jon Smirl wrote:

Xerces offers a fully thread safe parser and DOM. It is also one of the
slowest DOMs in existence. This DOM is especially slow on SMP machines where
every memory alloc and DOM access involves a multi-CPU thread lock.

Xalan was originally built using the Xerces DOM. Xalan has since replaced
the Xerces DOM with it's own internal DOM and only uses Xerces for SAX-like

Currently Xerces and Xalan have a single static initialization which needs
to be thread safe. All other global information it is stored in processor
objects which are private to a thread.

In general adding thread safety was a very bad experience on Xerces/Xalan.
This is much better handled at a higher level.

The assertion in the second sentence may be true (I don't think so,
but it may), but it's a non-sequitur from the evidence you've offered.
There are certainly plenty of good as well as bad examples of threading
performance, and there's nothing special in the nature of libxml's task
that makes it particularly ill-suited to threading.

The Solaris kernel is the best thread implementation ever seen, and the
Sun guys have a reputation for telling people exactly how to make threaded
programs fly on their massive MP systems.  Therefore, I am willing to
give Gary the benefit of the doubt that he knows what he's doing and
can make this not suck.  Your example reflects poorly on Xalan's skills,
but not on Gary's proposal.

Todd Lewis
tlewis mindspring com

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]