ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jose Alberto Fernandez" <jalbe...@cellectivity.com>
Subject RE: Macrodef and parallel in a recursive situation
Date Sat, 18 Oct 2003 15:22:15 GMT
> From: peter reilly [mailto:peter.reilly@corvil.com] 
> 
> 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:peter.reilly@corvil.com]
> > >
> > > 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: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org


Mime
View raw message