«

Anybody out there who knows if the 4suite implementation of XSLT are a
threadsafe one?

--
--------------------------------------
Ola Natvig <>
infoSense AS / development

Ola Natvig wrote:

> Anybody out there who knows if the 4suite implementation of XSLT are a
> threadsafe one?

What do you mean by that? You can of course transform xml using xslt in as
many threads as you like - but what do you want with two or more threads in
_one_ transformation? You start it, and some time later the result is
there.

--
Regards,

Diez B. Roggisch

Diez B. Roggisch wrote:
> Ola Natvig wrote:
>
>
>>Anybody out there who knows if the 4suite implementation of XSLT are a
>>threadsafe one?
>
>
> What do you mean by that? You can of course transform xml using xslt in as
> many threads as you like - but what do you want with two or more threads in
> _one_ transformation? You start it, and some time later the result is
> there.
>

If a thread that are using a XSLT processor looses the GIL within the
transformation process and another one starts processing on the same
processor will this work?

Will the half-way finished thread be in the way of the one starting the
processing before the stoped thread are done.

I think that's what I ment. Can a XSLT processor object be shared
between multiple threads?

--
--------------------------------------
Ola Natvig <>
infoSense AS / development

Diez B. Roggisch wrote:

> What do you mean by that? You can of course transform xml using xslt in as
> many threads as you like

It is not unthinkable that some parts of the library would not be
threadsafe. They could have some internal shared global variable
that keeps track of an intermediate state.
Some C string processing functions are not thread safe either.


Istvan.

Istvan Albert wrote:
> Diez B. Roggisch wrote:
>
>> What do you mean by that? You can of course transform xml using xslt
>> in as
>> many threads as you like
>
>
> It is not unthinkable that some parts of the library would not be
> threadsafe. They could have some internal shared global variable
> that keeps track of an intermediate state.
> Some C string processing functions are not thread safe either.
>
>
> Istvan.

It looks like there are some problems with multiple threads accessing
the the processor 'at once', think I'll write som kind of syncronizing
wrapper or supply multiple processors to the threads.

--
--------------------------------------
Ola Natvig <>
infoSense AS / development

> It is not unthinkable that some parts of the library would not be
> threadsafe. They could have some internal shared global variable
> that keeps track of an intermediate state.
> Some C string processing functions are not thread safe either.

While the only one how can answer this is Uche himself, I'm confident that
this is not the case - modern OO-style apis associate state usually on a
per-object base. And 4suite is heavily OO-styled.

--
Regards,

Diez B. Roggisch

> If a thread that are using a XSLT processor looses the GIL within the
> transformation process and another one starts processing on the same
> processor will this work?
>
> Will the half-way finished thread be in the way of the one starting the
> processing before the stoped thread are done.
>
> I think that's what I ment. Can a XSLT processor object be shared
> between multiple threads?

No - as a simple test reveals:

#The identity transform: duplicates the input to output
TRANSFORM = """<xsl:stylesheet
xmlnssl="http://www.w3.org/1999/XSL/Transform" version="1.0">

<xsl:template match="@*|node()">
<xsl:copy>
<xsl:apply-templates select="@*|node()"/>
</xsl:copy>
</xsl:template>

</xsl:stylesheet>
"""

#And I don't even like Monty Python, folks
SOURCE1 = """<spam id="eggs">What do you mean "bleah"</spam>"""
SOURCE2 = """<spam id="eggs">I don't like spam</spam>"""

import threading
from Ft.Xml.Xslt import Processor
processor = Processor.Processor()
import time, sys
from Ft.Xml import InputSource

transform = InputSource.DefaultFactory.fromString(TRANSFORM,
"http://spam.com/identity.xslt")

processor.appendStylesheet(transform)

#Now the processor is prepped with a transform and ccan be used
#over and over for the same transform
results = []
source = InputSource.DefaultFactory.fromString(SOURCE1,
"http://spam.com/doc1.xml")
source2 = InputSource.DefaultFactory.fromString(SOURCE2,
"http://spam.com/doc2.xml")
threading.Thread(target=lambda:
results.append(processor.run(source))).start()
# comment the following line to make things crash.
time.sleep(5)
threading.Thread(target=lambda:
results.append(processor.run(source2))).start()

time.sleep(5)
print results


--
Regards,

Diez B. Roggisch

> While the only one how can answer this is Uche himself, I'm confident that
> this is not the case - modern OO-style apis associate state usually on a
> per-object base. And 4suite is heavily OO-styled.

I should have added that this means that using a api like 4suite where you
can get a processor for one transformation, it should be safe to get
another one in another thread for another transformation, as this is the
preceived use case.

--
Regards,

Diez B. Roggisch

Sorry I'm late to the whole thread. Diez B. Roggisch is pretty much
right on the money in all his comments. 4XSLT *is* thread safe, but
each individual processor instance is not thread safe. Yes, this is
typical OO style: you encapsulate state in an instance so that as long
as each thread has its own instance, there are no state clashes.

Therefore, you should be creating at least one processor object per
thread.

Note: the 4Suite server is a multi-threaded architecture that uses
4XSLT heavily using processor-per-thread.

--
Uche Ogbuji Fourthought, Inc.
http://uche.ogbuji.net http://4Suite.org http://fourthought.com
Use CSS to display XML -
http://www.ibm.com/developerworks/ed...-xmlcss-i.html
Introducing the Amara XML Toolkit -
http://www.xml.com/pub/a/2005/01/19/amara.html
Be humble, not imperial (in design) -
http://www.adtmag.com/article.asp?id=10286UBL 1.0 -
http://www-106.ibm.com/developerwork...x-think28.html
Manage XML collections with XAPI -
http://www-106.ibm.com/developerwork...ry/x-xapi.html
Default and error handling in XSLT lookup tables -
http://www.ibm.com/developerworks/xm...x-tiplook.html
Packaging XSLT lookup tables as EXSLT functions -
http://www.ibm.com/developerworks/xm...-tiplook2.html