Java based XML parsers for server use.

[David Brownell]

>  > See my other response on the related thread. We have chosen what we
>  > consider the correct level of granularity for thread safety, which
>  > is at the per-parser level.

In fact, many of us long ago concluded that the term "thread safe" was
so ambiguous as to be confusing.  There are different levels of safety,
and then there's also being "multithread-hot" in some applications.


> The point here, I suspect, is not that it is not a good idea to have
> multiple threads inside the same parser, but that it is not a good
> idea to use the same parser in multiple threads outside of it.

I confess to having parsing problems with that sentence ... what's
the antecedent to that last "it" ?  :-)


> I can imagine a parser some day running several internal threads on a
> multiprocessor machine -- one, perhaps, for I/O, one for tokenisation,
> one for structure recognition, and one for schema-based validation.  I
> don't know if I'd bother doing this right now, since single-threaded
> parsers are so fast anyway, but who knows what tomorrows technology
> and business requirements will be?

Surely not me!  But parsing isn't normally thought of as something
that's naturally parallel.  I think that it's the higher level tasks
(perhaps driven by application-specific schemas) that will be the
places where "multithread-hot" applications start to kick in.

That gets again to those rules of thumb I alluded to earlier:  first,
that synchronization is confusing and not free, so avoid it; second,
in consequence, only do synchroniziation (concurrent operations) at
a relatively coarse grain, where there's a significant win!  That's
often higher up in the application stack (e.g. N clients working at
the same time) than it is low down in that stack.

- Dave

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev at ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To (un)subscribe, mailto:majordomo at ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo at ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa at ic.ac.uk)