Re: [xml] libxml2 thread safety

[tlewis mindspring com]

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
> events.
>
> 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