- From: Romain Deltour <rdeltour@gmail.com>
- Date: Thu, 1 Sep 2011 21:22:12 +0200
- To: XProc Dev <xproc-dev@w3.org>
(Reviving this old thread about Calabash thread-safety) Once an XProcConfiguration object has been created and configured, it seems the only thing that prevent it to be reused to create multiple runtimes is that the underlying Saxon Processor is registered with XPath extension functions depending on an XProcRuntime: The processor is registered with functions tied to the latest XProcRuntime created, holding contextual information such as the XProcData stack, which makes it impossible to be used in multiple threads. Note that a Saxon Processor is usually a reusable thread-safe object. A quick fix that makes the XProcConfiguration reusable is to return new Processor objects in the XProcConfiguration#getProcessor() method. A better solution would be to use thread-safe extension functions, for instance holding the XProcRuntime dependency in a ThreadLocal variable. This can be tracked in Issue 153: http://code.google.com/p/xmlcalabash/issues/detail?id=153 Romain. Le 16 juin 10 à 22:33, David a écrit : > When I worked with Norm on this issue last year the conclusion is > that Calabash is definitely NOT thread safe for sharing > XProcConfigurations, > there are things it does during the lifetime of a single pipeline > run that affect this state. It should not be shared across threads. > However neither of us were able to find any obvious concurrency > problems if you dont share XProcConfigurations between threads. > Not to say that there isn't, but neither of us found anything obvious. > I have not had problems but have not exhaustively tested concurrent > use. > > ------------------------- > David A. Lee > dlee@calldei.com > http://www.calldei.com > http://www.xmlsh.org > > > On 6/16/2010 4:21 PM, Romain Deltour wrote: >> Note that in this context you need to be careful of thread safety, >> since the Servlet code will be invoked concurrently. >> >> I don't know if Calabash is thread safe, notably if you can reuse >> a single XProcConfiguration concurrently. You could create a new >> XProcConfiguration for each call, however I guess it is less >> efficient than if you could share it (and notably the underlying >> Saxon Processor) among concurrent calls. >> >> Romain. >> >> >> Le 16 juin 10 à 07:18, Chris Maloney a écrit : >> >>> Seems like it would make sense. I'm just wondering if it would be >>> easy to adapt it, or not. >>
Received on Thursday, 1 September 2011 19:22:52 UTC