[
Lists Home |
Date Index |
Thread Index
]
On Fri, 31 Dec 2004 11:57:44 -0500, Alan Gutierrez
<alan-xml-dev@engrm.com> wrote:
> * Uche Ogbuji <uche.ogbuji@fourthought.com> [2004-12-30 23:00]:
> > On Thu, 2004-12-30 at 19:50 -0800, Bob Foster wrote:
<snip>discussion on thread death</snip>
>
> Hi. OP, here. It was all very illuminating.
>
> It tells me that SAX, as an API, is missing support for parallel
> processing. Parellel porcessing is possible in SAX, or rather,
> it is possible with ContentHandler implementations that were
> co-operative and synchorized, but then you're forgetting an
> interface to specify ContentHandlers, and a bunch of other whatnot.
>
> As such, parallel SAX, doesn't make much sense, but parallel
> processing of streaming XML is not, for some reason that I could
> not see, impossible.
I don't think either is precluded, but working from serialized strings
as your input source isn't going to get you very far. However, you
could specify data structures explicitly for such parallel processing
(and indeed I once designed a portion of a hardware instruction set
specifically for parallel tree processing many years ago). In
particular, in Java terms think of a Collection of Collections (you
actually need more complicated data structures) as your basic tree
structure. If the contents of any given entry are a string you spit
it out, otherwise you recurse. For any given level of collection you
could essentially process all entries in the collection in parallel
and pass any child collections on for further (parallel) processing.
As has been pointed out, buffering of the results dependant on
dispatch order may negate some (much?) of the advantages of parallel
processing for some use cases; wide trees with the occasional deep
structure would seem to be particularly bothersome... OTOH, throwing
the results of simple SQL queries into a collection structures might
get you somewhere.
--
Peter Hunsberger
|
