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
compatibility...
The MSDN docs for System.Xml.Xsl.XslTransform say XslTransform objects
are only thread-safe for transform operations, which implies they
msxsl:script cannot be thread safe on transform operations as script
writers could write any thread-unsafe operations. If MSDN says it
is thread safe for transformation, then that is wrong. If it were
correct, it requires whatever no one can achieve.
Atsushi Eno
Joshua Tauberer wrote:
Okay, so,
XSLTCompiledTransform is thread-safe. Would that be an alternative
for you?
- Steve
--
Steve G. Bjorg
http://wiki.mindtouch.com
http://twitter.com/bjorg
On Jul 17, 2008, at 6:54 AM, Joshua Tauberer wrote:
Okay, so, clearly I'm only writing more because it makes my life
Atsushi Eno wrote:
msxsl:script cannot be thread safe on transform operations as script
writers could write any thread-unsafe operations.
Well, sure. There's lots a script can do to mess up the application, and
it seems like scripts in transformations basically need full trust
anyway because
Joshua Tauberer wrote:
If MSDN says it is thread safe for transformation, then that is wrong.
If it were correct, it requires whatever no one can achieve.
Not to go all semantics on you, but an API can't be wrong. Inconsistent,
What I said wrong here is MSDN documentation, not API (and
Steve Bjorg wrote:
XSLTCompiledTransform is thread-safe. Would that be an alternative for
you?
As far as I know, XSLTCompiledTransform (in Mono) just wraps the same
code as XslTransformation, so they are equally thread safe.
The MSDN docs seem to basically say the same thing w.r.t. thread
Hmm, except the docs for XsltCompiledTransform explicitly states that
the object is thread-safe once loaded.
Thread Safety
The XslCompiledTransform object is thread safe once it has been
loaded. In other words, after the Load method has successfully
completed, the Transform method can
Well, for one, it would be thread-safe if its only state where stored
in the invocation stack instead of the object, but that's besides the
point. :)
From doing a search on the topic, it appears that Microsoft and MVPs
alike are promulgating the myth of thread-safety for the Transform()
From time to time I encounter index out of range errors in
Mono.Xml.Xsl.XslSortEvaluator during my multi-threaded use of a single
XSLT transform object, which I think was due to modifying the state of a
XslSortEvaluator object during the processing of a document.
I'm pretty sure the attached
Hey,
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
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
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
12 matches
Mail list logo
