PageSequenceLayoutManager implements Runnable,
theoretically to allow for the layout of each page
sequence on separate threads.  The more complex
logical aspects needed for this to happen (e.g., idref
resolution, page numbering) though are not
implemented, rendering this feature not very useful. 
We're not using Runnable now, and so I'd like to yank
it before the upcoming release--it is easy to place it
back in later if we do this in the future releases
(although the more extensive logic will still need to
be developed).  Thoughts?  Objections?

I don't see multithreading page-sequence layouts as a
certainty ATM because:

(1) multithreading may not be workable/worthwhile
given the layout process and the dependences of one
page sequence upon another

(2) multithreading may not buy us anything
performance-wise: instead of:

F-PS1 --> L-PS1 --> F-PS2 --> L-PS2 --> F-PS3 -->

(Where F-PS1 means "create FO Tree for page sequence
and L-PS1 means "layout page sequence 1", etc.)

Multithreading might mean:
F-PS1 --> (F-PS2, L-PS1) --> (F-PS3, L-PS1, L-PS2) -->
(L-PS2, L-PS3)

But cycles spent on getting F-PS2 done earlier (i.e.,
before L-PS1 is finished) end up slowing down L-PS1 by
an equivalent rate, and because of context switching,
performance would appear to be actually worse.

(3) whether we have the multithreading at the wrong
level--i.e., normally, it would appear that the SW
that embeds FOP would do the multithreading (i.e., a
servlet which runs multiple FOP reports, one for each
thread), not FOP itself.  Having dual levels of
multithreading appear suspect to me--I doubt Xalan
goes that route.


Reply via email to