On 07.09.2004 21:11:09 Finn Bock wrote: > [Jeremias Maerki] > > > Question to everyone: We currently don't have a multi-threaded design > > like Peter West's approach. Can anyone think of a reason that all the > > FO-building and layouting process for one processing run may run within > > more than one thread? I don't think threre is one if the SAX event > > delivery is always within one thread (big if). If there isn't I believe > > we could make use of a ThreadLocal to put some shared data that will be > > easily accessible from all involved components. Initialize the > > ThreadLocal in startDocument() and clear it in endDocument(). I realize > > there's a certain risk involved but it could really shorten the access > > ways for shared data especially for the FO tree, if that's really a > > problem (I'd also like to know if it really is. Anyone?). > > A (farfetched) argument against ThreadLocals would be that they prevent > one FOP processing run to occur recursively during another independent > processing run. Like an extension element that itself will attempt to > process another fo document.
Good point, actually. IMO FOP should support rendering documents snippets. One use case for this is an FO paragraph or two within SVG (FO embedded in SVG embedded in FO). And what a coincidence: I've had a discussion exactly today where we talked about rendering FO snippets to EMF (Windows enhanced metafile format) for inclusion in a Win32-based reporting engine. > My preference would be to explicit pass the shared data (in this case > the FOEventHandler) to the classes that needs it. If the recursion Glen > discovered is deemed too slow, then store the FOEventHandler in an > instance field for each FONode. My preference, too. But having too much in FONode will generate a lot memory consumption. Just the logger instance in the maintenance branch takes up a lot of memory. As long as we can keep such a reference to count one I don't think this is such a big problem, however. The ThreadLocal was just an intriguing idea but your comment already lets me dismiss it. It's probably more trouble than it's worth. Jeremias Maerki
