[Mono-dev] Patch: XSLT thread safety

Joshua Tauberer jit at occams.info
Thu Jul 17 09:54:46 EDT 2008

Okay, so, clearly I'm only writing more because it makes my life easier 
to have the patch in, and not because I particularly care about API 

The MSDN docs for System.Xml.Xsl.XslTransform say "XslTransform objects 
are only thread-safe for transform operations," which implies they are 
intended to be thread safe in the manner I suggested. (I didn't mention 
this initially because the docs for the Transform method don't mention 
anything about thread safety so I didn't think it was a part of the API. 
But I thought that it was suspicious because it is an obvious candidate 
for a thread-safe method, so I checked again.)

I'm not sure how msxsl:script works or why it would be a problem...?

- Josh Tauberer


"Yields falsehood when preceded by its quotation!  Yields
falsehood when preceded by its quotation!" Achilles to
Tortoise (in "Godel, Escher, Bach" by Douglas Hofstadter)

Atsushi Eno wrote:
> No. Because sorting could happen a lot.
> Also, your patch brings wrong assumption that every XslTransform
> must be immutable, even when msxsl:script is involved (and I don't
> think we welcome "x is thread safe" "y is not" sort of complication).
> You are anyways standing on wrong premise anyways. Create multiple
> XslTransform for each thread. Since newobj happens a lot, it shouldn't
> be a big problem (for you at least).
> Atsushi Eno
> Joshua Tauberer wrote:
>> Atsushi Eno wrote:
>>> Thanks for the patch, but I don't think it makes things better.
>>> It adds extra newobj cost at every transformation time, while we
>>> could just do it only once. And XslTransform does not have to be
>>> thread safe. If you use XslTransform in multithread scenario, you
>>> must create XslTransform for each thread.
>> Can't the benefits outweigh the costs? There are plenty of newobj's 
>> throughout XSLT. One more isn't going to change much, and as far as 
>> I've found it's the only thing preventing XSLT from being thread safe, 
>> which is a big plus (for me at least).

More information about the Mono-devel-list mailing list