W3C home > Mailing lists > Public > public-xml-processing-model-wg@w3.org > March 2008

An example of guaranteed proper protection against potential race conditions

From: Henry S. Thompson <ht@inf.ed.ac.uk>
Date: Thu, 20 Mar 2008 17:30:46 +0000
To: public-xml-processing-model-wg@w3.org
Message-ID: <f5br6e5l2ux.fsf@hildegard.inf.ed.ac.uk>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Suppose I have a document which changes slowly over time, which is to
be styled by a document-dependent stylesheet.  There is a simple XPath
test to determine whether or not I need to build a new stylesheet,
which is an expensive process.  If no new stylesheet is needed, I use
the existing one.  Here's an unsafe pipeline which tries to do this.

<p:pipeline type="main">
 <p:choose>
  <p:when test="[some property of the primary input]">
   [expensive series of steps]
   <p:store href="file:///home/ht/stylesheets/clever.xsl"/>
   <p:sink/>
  </p:when>
  <p:otherwise>
   <p:sink/>
  </p:otherwise>
 </p:choose>
 <p:xslt>
  <p:input>
   <p:pipe step="main" port="source"/>
  </p:input>
  <p:input>
   <p:document href="file:///home/ht/stylesheets/clever.xsl"/>
  </p:input>
 </p:xslt>
</p:pipeline>

There's no guarantee here that the XSLT step will see the updated
stylesheet in the case that one is written.

The following pipeline fixes this:

<p:pipeline type="main">
 <p:choose>
  <p:when test="[some property of the primary input]">
   [expensive series of steps]
   <p:store href="file:///home/ht/stylesheets/clever.xsl"/>
  </p:when>
  <p:otherwise>
   <p:identity>
    <p:input>
     <p:inline>
      <c:result>file:///home/ht/stylesheets/clever.xsl</c:result>
     </p:inline>
    </p:input>
   </p:identity>
  </p:otherwise>
 </p:choose>
 <p:load name="doload">
  <p:option name="href" select="."/>
 </p:load>
 <p:xslt>
  <p:input>
   <p:pipe step="main" port="source"/>
  </p:input>
  <p:input>
   <p:pipe step="doload" port="result"/>
  </p:input>
 </p:xslt>
</p:pipeline>

Richard suggests the following alternative, but I'm not convinced:

<p:pipeline type="main">
 <p:choose name="choice">
  <p:when test="[some property of the primary input]">
   [expensive series of steps]
   <p:store href="file:///home/ht/stylesheets/clever.xsl"/>
  </p:when>
  <p:otherwise>
   <p:identity>
    <p:input port="source"/>
     <p:inline><a/></p:inline>
    </p:input>
   </p:identity>
  </p:otherwise>
 </p:choose>
 <p:xslt>
  <p:param name="my:serialiseSteps" select='.'>
   <p:pipe step="choice" port="result"/>
  </p:param>
  <p:input>
   <p:pipe step="main" port="source"/>
  </p:input>
  <p:input>
   <p:inline>
    <xsl:stylesheet>
     <xsl:import href="file:///home/ht/stylesheets/clever.xsl"/>
    </xsl:stylesheet>
   </p:inline>
  </p:input>
 </p:xslt>
</p:pipeline>

on the grounds the step can't run until the parameter binding is
available, which in turn guarantees that the new stylesheet has been
written.

I'm not convinced.  My desired optimising pipeline engine realises
that stylesheets and schema documents are huge bottlenecks, and one of
the main options for improving efficiency is to precompile all static
resources of such a kind.  Such an engine will not do the 'right'
thing with the above pipeline, _unless_, as the implementation I have in
mind does, the compiled (stylesheet,schema) cache entries are
annotated with the write-dates of all the resources involved in their
compilation, and these are always checked before using a cache entry.

Since I presume we don't want to go into that kind of detail in the
spec., we need to say something along the lines of what Murray said,
namely that read/write dependencies which go outside the pipeline
cannot in general be relied on. . .

ht
- -- 
 Henry S. Thompson, HCRC Language Technology Group, University of Edinburgh
                     Half-time member of W3C Team
    2 Buccleuch Place, Edinburgh EH8 9LW, SCOTLAND -- (44) 131 650-4440
            Fax: (44) 131 650-4587, e-mail: ht@inf.ed.ac.uk
                   URL: http://www.ltg.ed.ac.uk/~ht/
[mail really from me _always_ has this .sig -- mail without it is forged spam]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)

iD8DBQFH4p9GkjnJixAXWBoRAl2EAJ0c3g1PKVpHq9Rha+bIgHIsjTbE/QCfapz+
hEx1HEjRqpZIIIbcnH4HFo8=
=amj9
-----END PGP SIGNATURE-----
Received on Thursday, 20 March 2008 17:31:24 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 20 March 2008 17:31:25 GMT