[Mono-dev] Patch: XSLT thread safety
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