[
Lists Home |
Date Index |
Thread Index
]
Uche Ogbuji wrote,
> I don't see why a parallelized streaming architecture could not be
> expressed in terms of SAX events. Perhaps you could persuade me SAX
> does not allow it, but I expect that this would be only by admitting
> to precious and entirely unnecessary restrictions in the definition
> of SAX.
I didn't say it couldn't.
What SAX-Java doesn't (or at least, definitely shouldn't) allow is a SAX
parser delivering two or more events relating to the same parse to the
same ContentHandler concurrently.
Why not? Trivial example,
class SomeContentHandler implements ContentHandler {
public void startElement(
String ns, String local, String qname, Attributes atts) {
// Do startElement stuff, eg. push name on internal stack
}
public void endElement(
String ns, String local, String qname) {
// Do endElement stuff, eg. pop name off internal stack
}
}
If these methods could be invoked concurrently the expected invariant
that startElement completes before endElement is entered would be
violated and the code would break horribly. So portable code which
depended on that behaviour (almost every ContentHandler I've ever seen)
would have to be rewritten to reinstate it. That would be _extremely_
ugly.
Note the the prohibition on concurrent event delivery doesn't prevent
you from registering a single ContentHandler with two or more parsers
and running each of them in a separate thread (tho' implementing a
ContentHandler that could do something useful safely in such
circumstances would be fiddly). Nor does it prevent you from building a
specialized SAX parser and having it deliver the events corresponding
to a single parse to two or more ContentHandlers each in a separate
thread.
Is that enough for what you want?
Cheers,
Miles
|
