ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Peter Reilly" <peter.kitt.rei...@gmail.com>
Subject Re: Local Properties
Date Wed, 22 Aug 2007 16:44:28 GMT
On 8/22/07, Matt Benson <gudnabrsam@yahoo.com> wrote:
> Apologies for the top post but yours was rather long.
> ;)  I like the approach patch; I have applied it but
> don't have time to exercise it ATM.  The only issue I
> see is that I am apparently too stupid to understand
> how copying the current stack for new threads works.
> What I see:
>
> <parallel> kicks off a given TaskRunnable t in its own
> thread.
> t.run() gets the LocalProperties for the current
> project and calls copy().
> LP.copy() copies/replaces its own current LPStack.
>
> but the current LPStack is the ThreadLocal value, so
> getting that value under the authority of the
> TaskRunnable thread should yield a new LPStack,
> generated by LP.initialValue(), no?  Isn't the
> objective here to copy the new stack from the parent
> stack?  Shouldn't the copy then take place under the
> originating thread?  What am I missing here?

I actually have not yet tested this part. ----)

But the way it is meant to work (and maybe it does work)
is that all threads get a reference to the stack from
the parent thread (a lot of threads get created for
example with IO processing of sub processes),
but for these cases there is only one ant thread
creating and destroying macroinstances.

For parallel, the idea is that a shallow copy is made of
the property stack and this is set to the threadlocal value
so that each the parraled threads would
have own copy of the stack.

Peter

>
> -Matt
>
> --- Peter Reilly <peter.kitt.reilly@gmail.com> wrote:
>
> > Hi all,
> > I have updated the local properties patch to
> > make use of the new PropertyHelper delegate
> > infrastructure.
> > (see:
> >
> http://issues.apache.org/bugzilla/show_bug.cgi?id=23942)
> >
> > The idea behind local properties is to provide
> > isolation of properties within element blocks - like
> > macrodefs and sequential. The main use case of
> > course is for macrodefs.
> >
> > With current macrodefs, there is a number of
> > work-arounds
> > to handle the fact that ant properties are global
> > and unmodifiable
> > (i.e. write once).
> >  1) invent a new name based on attribute values
> >  2) use ac:var unset="yes"
> >
> >    for example:
> >     <macrodef name="remove-log4js">
> >        <attribute name="destdir">
> >         <element name="jars" implicit="yes"/>
> >        <sequential>
> >             <mkdir dir="@{destdir}"/>
> >             <ac:for parm="jar">
> >                 <jars/>
> >                 <sequential>
> >                      <basename
> > property="jarfile-@{jar}" file="@{jar}"/>
> >                      <remove-log4j srcfile="@{jar}"
> > dstfile="@{destdir}/no-log4j-${jarfile-@{jar}}"/>
> >                </sequential>
> >             </>
> >          </>
> >      </>
> >
> > or: (2):
> >                      <ac:var name="jar-base-name"
> > unset="yes"/>
> >                      <basename
> > property="jar-base-name" file="@{jar}"/>
> >                      <remove-log4j srcfile="@{jar}"
> > dstfile="@{destdir}/no-log4j-${jar-base-name}"/>
> >
> > Both of these methods pollute the global property
> > namespace with properties
> > that are just mean to be used internally within the
> > macrodef instance.
> >
> > The <local> property patch makes a property that is
> > only alive within
> > a particular scope.
> >
> > So the above code becomes:
> >                    <local name="jar-base-name"/>
> >                    <basename
> > property="jar-base-name" file="@{jar}"/>
> >                    <remove-log4j srcfile="@{jar}"
> > dstfile="@{destdir}/no-log4j-${jar-base-name}"/>
> >
> > and on exit from the macro, there would be no
> > "jar-base-name" property.
> > And it there was a global "jar-base-name" property,
> > it would *not* be
> > overwritten,
> > or used within the macrodef.
> >
> > The <local> patch uses the following elements for
> > block scopeing -
> > <target> and <sequential>.
> >
> > (I think that this could be restricted to just
> > <sequential>).
> >
> > Peter
> >
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail:
> > dev-unsubscribe@ant.apache.org
> > For additional commands, e-mail:
> > dev-help@ant.apache.org
> >
> >
>
>
>
>
> ____________________________________________________________________________________
> Choose the right car based on your needs.  Check out Yahoo! Autos new Car Finder tool.
> http://autos.yahoo.com/carfinder/
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
> For additional commands, e-mail: dev-help@ant.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org


Mime
View raw message