> From: peter reilly [mailto:[EMAIL PROTECTED] > > I think that we may need a thread local variable to > handle parallel. > > This would mean some deep messing with the Property handling. >
I do not see how thread locals would help here. I guess the question is whether tasks in parallel should be able to modify the global properties in the frame, or should the changes be local to the parallel branch (and somehow joined at the end of execution). That would mean each parallel computation branch is independent. I guess I am suggesting the second type of implementation proposed for <local-property> to be used instead for <parallel>. I think that would be a much more efficient way to do it. So here is how it would work: 1) Add new attribute independent (default false) to <parallel>. 2) When independent is true, each thread will use a cloned project frame for its execution. So all properties and reference manipulation will be independent of each other. When the thread ends, any new properties added in the cloned frame, will be added to the original parent frame, following the common rules for setting properties. Which means that the first thread that finish will win on setting the property, if another thread ends later and tries to set the same variable, it will loose. For references, we need to copy any changes and due to its semantics all threads will contribute as they end. 3) When independent is false, parallel works as today (for backward compatibility), all threads see each others changes. This rules seem easy programable without big changes to CORE. I would still like having <local-property> which could be implemented as per the first description proposed below. Jose Alberto > Peter > On Friday 17 October 2003 17:57, Jose Alberto Fernandez wrote: > > > From: peter reilly [mailto:[EMAIL PROTECTED] > > > > > > I would rather have Jose's idea of a <local-property/> task. > > > > > > This could be used outside of macrodef. > > > > > > The only problem is the implementation. > > > > Indeed, there is an easy implementation but will not solve > the case of > > <parallel>, because the local definition would really be a > temporary > > global one: > > > > public class LocalProperty extends Sequential { > > private String property; > > private String oldValue; > > > > public setName(String i_property){property = i_property;} > > > > public void execute() { > > if (property == null) throw new BuildException("name > attribute is > > mandatory"); > > try { > > oldValue = getProject().getProperty(property); > > getProject().setProperty(property, null); // This may need > > changes to core > > super.execute(); > > } > > finally { > > // This is using the deprecated setProperty method > > // that actually changes the properties even if set > > getProject().setProperty(property, oldValue); > > } > > } > > } > > > > Here we just change the property value on the project > frame, for the > > duration of the task. And put the old value back before we leave. > > > > The problem with this simple implementation is that all the > parallel > > branches will see the change, which is exactly what we were > trying to > > avoid. To do it > > right, we would need to create a new execution frame that > would be use > > in the > > "super" call. > > > > But if we do that (which is like what <ant> or <antcall> do), what > > happens if the user defines properties other than the > local-property > > inside the code? > > Somehow, we would need to find them and propagate them back > to the frame > > above > > upon exit. > > > > <local-property name="x"> > > <property name="y" value="myY"/> > > <local-property> > > <echo message="${y}"/> > > > > [echo] myY > > > > Doable, but not that easy anymore. > > > > What do you guys think? > > > > Jose Alberto > > > > > Peter > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
