[
Lists Home |
Date Index |
Thread Index
]
Yes, thanks for that.
I have a question, though. What is the guaranteed lifetime of an object
appearing in a SAX event, like an Attributes object, and any objects
used to implement it? If, for example, Attributes were implemented as a
collection of lightweight Attribute objects that were re-used for
subsequent events, the event data could not be passed directly to
parallel threads without copying it. (Or by joining at the end of every
event, which would rather limit the parallelism.)
Bob Foster
David Megginson wrote:
> I think that there's been a terrible amount of confusion on this thread.
>
> As soon as the filter pipeline design pattern started to become
> popular for applications based on SAX1, I assumed that people would
> insert tee-joints in the pipeline to allow for parallel processing
> when they needed it, especially since thread management in Java is so
> easy. Note that we're talking about parallel threads performing
> different operations on the *same* sequential event stream (i.e. one
> thread might be populating a database, while another is producing an
> HTML page). I can also conceive of applications where different
> threads deal with different parts of the document, as long as the
> source event stream stays single-thread and sequential -- for example,
> a filter might divert a series of events representing a document
> subtree to a separate thread that builds a data structure and performs
> time-consuming operations while the rest of the event stream continues
> on to the original thread (which was briefly suspended waiting for
> more input).
>
> So the source of the SAX event stream has to be sequential, but
> there's no reason that the rest of the filter pipeline cannot be
> parallelized.
>
>
> All the best,
>
>
> David
>
|
