4suite XSLT thread safe ?

O

Ola Natvig

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

Diez B. Roggisch

Ola said:
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.
 
O

Ola Natvig

Diez said:
Ola Natvig wrote:




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?
 
I

Istvan Albert

Diez said:
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.
 
O

Ola Natvig

Istvan said:
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.
 
D

Diez B. Roggisch

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.
 
D

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
xmlns:xsl="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
 
D

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.
 
U

Uche Ogbuji

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/edu/x-dw-x-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/developerworks/xml/library/x-think28.html
Manage XML collections with XAPI -
http://www-106.ibm.com/developerworks/xml/library/x-xapi.html
Default and error handling in XSLT lookup tables -
http://www.ibm.com/developerworks/xml/library/x-tiplook.html
Packaging XSLT lookup tables as EXSLT functions -
http://www.ibm.com/developerworks/xml/library/x-tiplook2.html
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,733
Messages
2,569,440
Members
44,832
Latest member
GlennSmall

Latest Threads

Top