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 non-deterministic. 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
