On 8/22/07, Matt Benson <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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="[EMAIL PROTECTED]" file="@{jar}"/> > > <remove-log4j srcfile="@{jar}" > > dstfile="@{destdir}/[EMAIL PROTECTED]"/> > > </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: > > [EMAIL PROTECTED] > > For additional commands, e-mail: > > [EMAIL PROTECTED] > > > > > > > > > ____________________________________________________________________________________ > 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: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
