468,549 Members | 2,219 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 468,549 developers. It's quick & easy.

4suite XSLT thread safe ?

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

--
--------------------------------------
Ola Natvig <ol********@infosense.no>
infoSense AS / development
Jul 18 '05 #1
8 1713
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
Jul 18 '05 #2
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.
Jul 18 '05 #3
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 <ol********@infosense.no>
infoSense AS / development
Jul 18 '05 #4
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 <ol********@infosense.no>
infoSense AS / development
Jul 18 '05 #5
> 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
Jul 18 '05 #6
> 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
--
Regards,

Diez B. Roggisch
Jul 18 '05 #7
> 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
Jul 18 '05 #8
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

Jul 18 '05 #9

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

1 post views Thread by Doug Farrell | last post: by
2 posts views Thread by Doug Farrell | last post: by
7 posts views Thread by Harolds | last post: by
4 posts views Thread by Jonathan Burd | last post: by
4 posts views Thread by WStoreyII | last post: by
1 post views Thread by jecheney | last post: by
13 posts views Thread by arun.darra | last post: by
12 posts views Thread by Peter K | last post: by
reply views Thread by NPC403 | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.