Ok, the FOEventHandler is created in the FOTreeBuilder. One FO
TreeBuilder is instantiated per processing run. The FOEventHandler is
set on FONode's static variable during startDocument(). The
FOEventHandler keeps track of used fonts, number of pages, tracking IDs
etc. which are all relevant to one document run.

Now imagine a situation where multiple processing runs occur and just
after the TreeBuilder sets the FOEventHandler on FONode in
startDocument() and continues layout, another thread starts another
processing run and runs through FOTreeBuilder.startDocument() before the
whole layout process of the first processing run is finished. The second
run will replace the FOEventHandler on FONode with a new one and the
first thread will suddenly work on a different FOEventHandler because
both threads access the same static variable. The behaviour will be

Statics are often handy and seductive but are very dangerous in a
multi-threaded environment. FOP is expected to work this way as many
mails on fop-user prove. Statics are fine for constants and mostly ok
for singletons and a few other opportunities, but I made it a rule for
myself to be very catious when I think about using a static variable. I
try to avoid them whenever possible.

On 06.09.2004 21:45:34 Glen Mazza wrote:
> Please elaborate.
> Jeremias Maerki wrote:
> >I'm sorry, Glen, but I think you will have to revisit that one. If I'm
> >not absolutely wrong, this will break multi-threading capabilities.
> >
> >On 06.09.2004 20:28:17 gmazza wrote:
> >  
> >
> >>gmazza      2004/09/06 11:28:17
> >>
> >>  Modified:    src/java/org/apache/fop/fo FONode.java FOTreeBuilder.java
> >>               src/java/org/apache/fop/fo/pagination Root.java
> >>  Log:
> >>  Switched to a static FOInputHandler object for the FOTree instead of relying on 
> >> recursion to get to the FOInputHandler object stored at pagination.Root.

Jeremias Maerki

Reply via email to