Re: An example of guaranteed proper protection against potential race conditions

May I propose another answer which do not rely at all on disk

I can imagine implementation that do load all file content before starting
so you don't have any chance to change what the implementation has in memory


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




On Thu, Mar 20, 2008 at 6:30 PM, Henry S. Thompson <ht@inf.ed.ac.uk> wrote:

>
> -----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/<http://www.ltg.ed.ac.uk/%7Eht/>
> [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-----
>
>


-- 
Innovimax SARL
Consulting, Training & XML Development
9, impasse des Orteaux
75020 Paris
Tel : +33 9 52 475787
Fax : +33 1 4356 1746
http://www.innovimax.fr
RCS Paris 488.018.631
SARL au capital de 10.000 €