You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ant.apache.org by Thomas Christen <ch...@active.ch> on 2000/12/03 20:03:38 UTC
[PATCH] Wait and Available (Updated)
Once again but this time without Tabs but indentation 4 Blanks and without
any reformatting of previous coding.
The attached zip contains
- A new Version of Available.java : New attributes "failonerror"
and "not"
- Updated Help for Available (available.htm)
- A new Task called Wait (See documentation wait.htm)
- A new Interface called SupportTasks : Used to mark
any task as a task supporting nested tasks
- A new Version of ProjectHelper.java :
- Constructor TaskHandler: Type of target changed to Object
- NestedElementHanlder: Method init changed a lot
- A new Version of Target.java : Only added implements
SupportTasks and use the new method perform() from
Task (see below)
- A new Version of Task.java : New method called perform() for
a centralised handling of task execution.
Any task can now implement nested tasks by implementing the Interface
SupportTasks. The task then has to take care during its own execution
and execute the nested tasks in the necessary sequence. The execution
of tasks should be done with the help of the new method perform() witch
will ensure, that all pre- and postactivities will be called at the right
stage of execution (e.g. Event handling, etc.)
Hope my adjustment are now according to the standards. Sorry for any
inconvenience.
Thomas
Re: [PATCH] Wait and Available (Updated)
Posted by Conor MacNeill <co...@cognet.com.au>.
Thomas,
I know it is annoying and I apologize for that. I'll try to get to your
patch and give you some feedback ASAP.
Conor
----- Original Message -----
From: "Thomas Christen" <ch...@active.ch>
To: <an...@jakarta.apache.org>
Sent: Tuesday, January 02, 2001 11:39 PM
Subject: RE: [PATCH] Wait and Available (Updated)
> Hopfully this sounds not impatient,
>
> I'd like to ask if there is anybody intersted in my two
> enhancements/extension
> (http://marc.theaimsgroup.com/?l=ant-dev&m=97587019310230&w=2) or should
I
> stop asking ?
>
> The problem I have, the 'Parallel' Task is nearly finished. But I had to
add
> some code to other classes and base on the functionality of the above
> mentioned Tasks. For me its anoying - always try to keep my localy
enhanced
> classes in synch with the repository.
>
> Thomas
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ant-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: ant-dev-help@jakarta.apache.org
>
Re: AW: [PATCH] Wait and Available (Updated)
Posted by James Duncan Davidson <du...@x180.net>.
On 1/4/01 12:04 PM, "Thomas Christen" <ch...@active.ch> wrote:
> Obviously we are all thinking in the similar direction.
>
> My concept is to pack this functionality in a separate task with nested
> (parallel tasks). This would give the implementation full controll about
> (output-/log-handling - don't underestimate, shutdown - e.g. by the gui and
> max number of concurrent tasks).
>
> The join (and not - Wait until available ;-)) ) is done automaticaly inside
> the controlling task.
That approach has merit in scoping, however it complicates the internal
object model that is given to Tasks. If Tasks are layered like this, then
when modifying the object model there's an extra dimension to the way
changes can be made. It's more flexible, but harder to wrap your head
around.
I'd prefer to leave the internal object model in a very clear
target-task-data kind of structure.
Also, I'm not sure that explicit scoping of the thread's range of execution
is needed. I've done threading for years with executing a thread.start()
method and just knowing that a thread is running out there now and that I
could .join it, but otherwise it was on its way.
.duncan
--
James Duncan Davidson duncan@x180.net
!try; do()
AW: [PATCH] Wait and Available (Updated)
Posted by Thomas Christen <ch...@active.ch>.
Obviously we are all thinking in the similar direction.
My concept is to pack this functionality in a separate task with nested
(parallel tasks). This would give the implementation full controll about
(output-/log-handling - don't underestimate, shutdown - e.g. by the gui and
max number of concurrent tasks).
The join (and not - Wait until available ;-)) ) is done automaticaly inside
the controlling task.
Thomas
> -----Ursprüngliche Nachricht-----
> Von: Conor MacNeill [mailto:conor@cognet.com.au]
> Gesendet am: Donnerstag, 4. Januar 2001 15:30
> An: ant-dev@jakarta.apache.org
> Betreff: Re: [PATCH] Wait and Available (Updated)
>
> Duncan,
>
> ----- Original Message -----
> From: "James Duncan Davidson" <du...@x180.net>
> To: <an...@jakarta.apache.org>
> Sent: Thursday, January 04, 2001 9:24 PM
> Subject: Re: [PATCH] Wait and Available (Updated)
>
>
> > In the TaskAction abstract base class would be a bit of functionality
> > provided for the setting of a 'thread="true|false"' attribute on any
> task.
> > What this would mean is that when Ant executed a task calling
> the execute
> > method on the TaskAction implementation, the abstract class
> functionality
> > would look to see if the 'thread' property had been set. If it had been,
> it
> > would spawn a thread, start execution of the TaskAction in it, and the
> > return control. When it started execution in a thread, it would register
> > that thread on a Scoreboard (and of course the proper thing is to have
> the
> > thread pull itself off the scoreboard when it is done).
> >
>
> I'm pretty comfortable with this since it is pretty much in line with my
> original multithreading patch. For the "scoreboard" I just used a
> vector of
> threads. The join task simply did a thread.join() on each thread until the
> vector was exhausted whereupon the join task would continue. The task
> thread themselves were unaware of the scoreboard and I think that is as it
> should be.
>
> > Example:
> >
> > <target name="main" depends="foo">
> > <javac srcdir="src/main" destdir="classes" thread="yes"/>
> > <javac srcdir="src/util" destdir="util-classes" thread="yes"/>
> > <join/>
> > </target>
> >
> > A core task would also be provided which would be effectively
> the "join".
> It
> > would check on the scoreboard until it cleared out, at which time it
> would
> > release the main thread to move on. Also, end of target should probably
> > imply a join -- at least of any threads spawned in that target.
>
> Yep, I believe the implicit join is required. In fact my join task simply
> activated the thread joining code present in the Target object,
> for the end
> of target join.
>
> There is one thing which I tried to consider, although not that well, and
> that is when an exception in thrown in one or more of the tasks. The
> TaskThread object I used to wrap a task in a thread would catch any
> exception thrown by the thread and store it. The join code would
> then query
> the TaskThread after the join operation and if an exception had
> been stored
> it would then rethrow it. The only problem was that I didn't then wait for
> the other threads to join :-) It would be simple to fix.
>
> >
> > This works all well except that Tasks that are checking the Object Model
> > might have things change on them. As well, they might want to wait until
> > thing are guaranteed stable (probably especially true of scripts). Part
> of
> > that might mean putting a "wait" call on the Object Model which would
> block
> > any threads entering that call unless/until the Scoreboard was clear.
> >
>
> The other problem would be other shared resources of which System.out is
> perhaps one of the most difficult to deal with. Currently some tasks, such
> as <java> are able to specify that the output is redirected to a file. If
> the java task is not forked, then System.out for the whole ant VM is
> redirected to the file. In a single threaded model that is cool, but a
> multithreaded model that could lead to some curious output being
> redirected. There may also be problems undoing the redirection.
>
> This flows into the GUI too since the concept of System.out and how it is
> handled in the GUI need to be thought about too.
>
> > So, that introduces complexity, but if we are going to support
> MT so that
> > you can max out your 8 processor MP boxen like some of my coworkers
> really
> > want to do, this seems the best way that I can think of to do it with a
> > minimum of impact to the build file syntax and maximum effectiveness of
> > multithreading any tasks. It *does* mean that Tasks have to be written
> like
> > Servlets and other MT beasts -- thread hot.
> >
> > I dunno whether it's worth it to make Task writer's life harder for
> > potential MT/MP benefits. It might be... I'm really kinda neutral and
> will
> > follow the crowd on this one. But this topic has come up enough, and I
> > didn't really like breaking the threading block into a sub element
> grouping,
> > that I dove in to take a thought. Comments?
> >
>
> I've never viewed MT in ant as a build performance issue - more
> the ability
> to do two things at once in a single build where those two things will
> typically be to run a server and run a junit test harness. BTW, when you
> try and do this you realize that you need a sleep task (or wait, perhaps)
> too, or some way of allowing the server to come up and knowing it has come
> up. Multiple ants is what I do today for this and it is OK but a single
> build, supporting "test often" would be nice.
>
> Conor
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ant-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: ant-dev-help@jakarta.apache.org
>
Re: [PATCH] Wait and Available (Updated)
Posted by Conor MacNeill <co...@cognet.com.au>.
> Or alternatively we could replace System.out with a custom PrintStream
that
> checked a ThreadLocalVariable to see which task it is associated with.
This
> sort of trick is oftend used in servlet/ejb containers.
>
Hmmm, that is possible. I'll think a bit more about that.
Conor
Re: [PATCH] Wait and Available (Updated)
Posted by Peter Donald <do...@apache.org>.
At 02:41 12/1/01 -0800, Steve Loughran wrote:
>I'm going to try coding up the soap proxy code generation task this w/end,
>using the javac design as a basis; I'll try out the notion of splitting out
>logging to see if it is viable and adequate.
It's viable and adequete and will most certainly go into Ant2.0 (at least
if I have anything to say about it ;-}) however anything that changes
backward compatability is not likely to go through with Ant1.x which I
suspect this will ... not sure ;)
Cheers,
Pete
*-----------------------------------------------------*
| "Faced with the choice between changing one's mind, |
| and proving that there is no need to do so - almost |
| everyone gets busy on the proof." |
| - John Kenneth Galbraith |
*-----------------------------------------------------*
Re: AW: [PATCH] Wait and Available (Updated)
Posted by Steve Loughran <st...@iseran.com>.
----- Original Message -----
From: "Peter Donald" <do...@apache.org>
To: <an...@jakarta.apache.org>
Cc: <an...@jakarta.apache.org>
Sent: Saturday, January 13, 2001 11:20 PM
Subject: Re: AW: [PATCH] Wait and Available (Updated)
> At 03:52 13/1/01 +0100, Thomas Christen wrote:
> >> If there was a separate interface for logging (called say Logger)
> >Well I did it a bit different. I was thinking rather of a logging
strategy
> >at task level.
> ...snip...
>
> um - you do realize that you do everything from this example via
> BuildListener/BuildLoggers ?
>
The nice thing about having a separate interface for logging (Like Thomas'
with a getOutputStream() method) is that classes which are not derived from
Task can talk to the current log without having to know about their owning
task.
Right now you end up having to carry a task reference around, often a couple
of levels deep just for the logging facility. Example:
(taskdefs.optional.dotnet.NetCommand holds onto a Task to pass to the
LogStreamHandler constructior )
If we had a separate interface then that is all that needs to be passed
in -or assigned to a TaskExecutionHelper which gets passed round. Then when
you parallelise code then it becomes easy to change the logger. But looking
at where the changes would need to go they are pretty 'deep'; not quite
Ant2.0 class of change, but probably an Ant1.4
NB: .Thinking of stuff to put into a TaskExecutionHelper class, there
another item that springa to mind is a touch(Date) method that obviates
having to create a new Touch task.
-Steve
Re: AW: [PATCH] Wait and Available (Updated)
Posted by Peter Donald <do...@apache.org>.
At 03:52 13/1/01 +0100, Thomas Christen wrote:
>> If there was a separate interface for logging (called say Logger)
>Well I did it a bit different. I was thinking rather of a logging strategy
>at task level.
...snip...
um - you do realize that you do everything from this example via
BuildListener/BuildLoggers ?
Cheers,
Pete
*-----------------------------------------------------*
| "Faced with the choice between changing one's mind, |
| and proving that there is no need to do so - almost |
| everyone gets busy on the proof." |
| - John Kenneth Galbraith |
*-----------------------------------------------------*
AW: [PATCH] Wait and Available (Updated)
Posted by Thomas Christen <ch...@active.ch>.
> -----Ursprüngliche Nachricht-----
> Von: Steve Loughran [mailto:steve_l@iseran.com]
> Gesendet am: Freitag, 12. Januar 2001 23:41
> An: ant-dev@jakarta.apache.org
> Betreff: Re: [PATCH] Wait and Available (Updated)
> You know, I've been thinking for a while about the feasibility of teasing
> out the logging methods into a separate interface.
So was I
> If there was a separate interface for logging (called say Logger)
Well I did it a bit different. I was thinking rather of a logging strategy
at task level.
public abstract class Task implements Logger {
public interface Logger {
void log(Task task, String msg, int msgLevel);
}
/** If defined - holds the reference to a Logger */
protected Logger loggerStrategy = this;
/**
* Setter for a new LoggerStrategy witch will handle all
* further log activities for this task.
* <p>
* @param loggerStrategy reference to a Logger witch will
* handle all subsequent log activities for this
* task
*/
public void setLoggerStrategy(Logger loggerStrategy) {
this.loggerStrategy = loggerStrategy;
}
--> change of old methode
/**
* Log a mesage with the given priority.
*
* @param the message to be logged.
* @param msgLevel the message priority at which this message is to be
logged.
*/
public void log(String msg, int msgLevel) {
loggerStrategy.log(this, msg, msgLevel);
}
--> end of change
/**
* Default implementation of the Logger - Strategy. Will be
* automaticely called in case no other Logger has been defined.
* <p>
* <b>Warning: </b>Do not call this methode directly. Use
* log(String, int) instead.
* <p>
* @see #log(String, int)
*/
public void log(Task task, String msg, int msgLevel) {
project.log(task, msg, msgLevel);
}
end exerpt of Task
If the executing part needs to change the logging behaviour, this can be
done by setting a different loggingStrategy. I did this within my new Task
"parallel" to implement 3 different logging strategies (the user should be
able to decide what strategy fits best) e.g. sequential (all logmsgs from
task 1, then all of task 2, etc.) or marked (all logmsgs ass son as they
apear but designated with an extra identifier to distinguish the msgs in
log.
The System.out has to be handled at Task level (like javac did). Therefor it
should be feasable to only take care about the logging.
It's all done but I'm still waiting to see my earlier proposals
(http://marc.theaimsgroup.com/?l=ant-dev&m=97587019310230&w=2) to be
implemented in the ant repository because the new functionality is based on
them.
Thomas
Re: [PATCH] Wait and Available (Updated)
Posted by Steve Loughran <st...@iseran.com>.
----- Original Message -----
From: "James Duncan Davidson" <du...@x180.net>
To: <an...@jakarta.apache.org>
Sent: Thursday, January 11, 2001 22:25
Subject: Re: [PATCH] Wait and Available (Updated)
> On 1/8/01 11:46 PM, "Peter Donald" <do...@apache.org> wrote:
>
> > Or alternatively we could replace System.out with a custom PrintStream
that
> > checked a ThreadLocalVariable to see which task it is associated with.
This
> > sort of trick is oftend used in servlet/ejb containers.
>
> There we go... :) That's the ticket. With a bit of buffer up on the end of
> that custom PrintStream, we can sort the output into the right blocks.
Cool.
>
You know, I've been thinking for a while about the feasibility of teasing
out the logging methods into a separate interface. The reason for that is
more and more tasks use separate classes (such as the new Javac framework)
to implement the real functionality, and these classes keep on being given
references back to the original task or project for the logging.
If there was a separate interface for logging (called say Logger) then
ant.Project and ant.Task could both interface it, the latter forwarding
calls to the interface stored in a task variable -which would be the project
by default. For something involving parallelisation, some other interface
could be assigned to that task which would log differently.
One of the benefits of this approach would be that we could execute many of
the ant tasks without having the rest of the framework in place -which would
make it easier for other programs to re-use these elements.
I'm going to try coding up the soap proxy code generation task this w/end,
using the javac design as a basis; I'll try out the notion of splitting out
logging to see if it is viable and adequate.
-Steve
Re: [PATCH] Wait and Available (Updated)
Posted by James Duncan Davidson <du...@x180.net>.
On 1/8/01 11:46 PM, "Peter Donald" <do...@apache.org> wrote:
> Or alternatively we could replace System.out with a custom PrintStream that
> checked a ThreadLocalVariable to see which task it is associated with. This
> sort of trick is oftend used in servlet/ejb containers.
There we go... :) That's the ticket. With a bit of buffer up on the end of
that custom PrintStream, we can sort the output into the right blocks. Cool.
--
James Duncan Davidson duncan@x180.net
!try; do()
RE: [PATCH] Wait and Available (Updated)
Posted by Peter Donald <do...@apache.org>.
At 02:38 9/1/01 +1100, Conor MacNeill wrote:
>if (threaded && redirecting && not forked) {
> throw new BuildException("Choose any two, baby");
>}
Or alternatively we could replace System.out with a custom PrintStream that
checked a ThreadLocalVariable to see which task it is associated with. This
sort of trick is oftend used in servlet/ejb containers.
Cheers,
Pete
*-----------------------------------------------------*
| "Faced with the choice between changing one's mind, |
| and proving that there is no need to do so - almost |
| everyone gets busy on the proof." |
| - John Kenneth Galbraith |
*-----------------------------------------------------*
Re: [PATCH] Wait and Available (Updated)
Posted by James Duncan Davidson <du...@x180.net>.
On 1/8/01 7:38 PM, "Conor MacNeill" <co...@ebinteractive.com.au> wrote:
> Unfortunately the <java> task can execute arbitrary java classes that can
> write to System.out. The <java> task contains two other facilities which
> complicate matters. The class can be run in the ant VM (fork="no") and it
> can redirect its output to a file. With those two combinations, the task
> will effectively redirect the Ant VM's System.out to the file. That won't
> work in a multithreaded model. In that case, we may need to allow a task to
> know if it is being run in a thread. The java task could then do something
> like
>
> if (threaded && redirecting && not forked) {
> throw new BuildException("Choose any two, baby");
> }
Yeah... One possibility is to capture System.out in some way -- it is a
settable variable on the System class.
Agreed that MT builds with Javac are going to produce bizzare output if
there are any problems with the compile... However, one possibility is to
give Javac an different ID depending on thread. So, when the compiler is
created:
sun.tools.javac.Main compiler =
new sun.tools.javac.Main(jos, "javac:" + threadid);
Then buffer the System.out to somewhere.. If the task failed, it could say
"Javac task failed. Error lines dumped in following block. Messages from the
failed build begin with 'javac:threadId'". -- then after printing this, the
System.out buffer could be dumped.
Another possibility is that there will be a JSR to define how compilers
should work - an API for compiling iow. A long term solution to this problem
could be found there.
--
James Duncan Davidson duncan@x180.net
!try; do()
RE: [PATCH] Wait and Available (Updated)
Posted by Conor MacNeill <co...@ebinteractive.com.au>.
Duncan,
> Yes. System.out as used by tasks has to go away. Instead they should be
> sending message events that have Task/Target identification so that the
> output tool can sort the output appropriately. A convenience .message()
> method can be provided on the Abstract Task implementation that wraps a
> given message as an Event so that task writers don't have to worry about
> building Event objects everywhere.
>
Unfortunately the <java> task can execute arbitrary java classes that can
write to System.out. The <java> task contains two other facilities which
complicate matters. The class can be run in the ant VM (fork="no") and it
can redirect its output to a file. With those two combinations, the task
will effectively redirect the Ant VM's System.out to the file. That won't
work in a multithreaded model. In that case, we may need to allow a task to
know if it is being run in a thread. The java task could then do something
like
if (threaded && redirecting && not forked) {
throw new BuildException("Choose any two, baby");
}
Conor
Re: [PATCH] Wait and Available (Updated)
Posted by James Duncan Davidson <du...@x180.net>.
On 1/4/01 6:29 AM, "Conor MacNeill" <co...@cognet.com.au> wrote:
> I'm pretty comfortable with this since it is pretty much in line with my
> original multithreading patch. For the "scoreboard" I just used a vector of
> threads. The join task simply did a thread.join() on each thread until the
> vector was exhausted whereupon the join task would continue. The task
> thread themselves were unaware of the scoreboard and I think that is as it
> should be.
Cool. This is about the only way that I've really resolved needing MT with
being clear.
>> A core task would also be provided which would be effectively the "join". It
>> would check on the scoreboard until it cleared out, at which time it would
>> release the main thread to move on. Also, end of target should probably imply
>> a join -- at least of any threads spawned in that target.
>
> Yep, I believe the implicit join is required. In fact my join task simply
> activated the thread joining code present in the Target object, for the end
> of target join.
We're about on the same page here. I'd acutally make the scoreboard code
external to both the join task and the end of target code so that it can
also be called by tasks which *have* to ensure that the tree won't change
under their feet. But it sounds like we're on the same page here.
> There is one thing which I tried to consider, although not that well, and
> that is when an exception in thrown in one or more of the tasks. The
> TaskThread object I used to wrap a task in a thread would catch any
> exception thrown by the thread and store it. The join code would then query
> the TaskThread after the join operation and if an exception had been stored
> it would then rethrow it. The only problem was that I didn't then wait for
> the other threads to join :-) It would be simple to fix.
Good point. If one of the spawned threads failed a build, it should fail at
the point where the join happens -- however, all the other threads before
that join should be able to complete appropriately if possible.
> The other problem would be other shared resources of which System.out is
> perhaps one of the most difficult to deal with. Currently some tasks, such
> as <java> are able to specify that the output is redirected to a file. If
> the java task is not forked, then System.out for the whole ant VM is
> redirected to the file. In a single threaded model that is cool, but a
> multithreaded model that could lead to some curious output being
> redirected. There may also be problems undoing the redirection.
Yes. System.out as used by tasks has to go away. Instead they should be
sending message events that have Task/Target identification so that the
output tool can sort the output appropriately. A convenience .message()
method can be provided on the Abstract Task implementation that wraps a
given message as an Event so that task writers don't have to worry about
building Event objects everywhere.
> I've never viewed MT in ant as a build performance issue - more the ability
> to do two things at once in a single build where those two things will
> typically be to run a server and run a junit test harness. BTW, when you
> try and do this you realize that you need a sleep task (or wait, perhaps)
> too, or some way of allowing the server to come up and knowing it has come
> up. Multiple ants is what I do today for this and it is OK but a single
> build, supporting "test often" would be nice.
Hmm. I guess we're coming at it from two different problem domains then.
Ending up at about the same place is a good thing then. Given that the only
threading primitive exposed in the buildfile is the simple attribute, and
that the join task is just a task, I don't have a problem with a wait task.
I guess the thing that convinced me that MT was a good pursuit was
contemplating doing a build on the 8 way machine downstairs in the lab and
really only being able to peg one processor and not be able to factor my
project so that I could potentially do bettter. But I see your side of
things as well here.
Cool.
--
James Duncan Davidson duncan@x180.net
!try; do()
Re: [PATCH] Wait and Available (Updated)
Posted by Conor MacNeill <co...@cognet.com.au>.
Duncan,
----- Original Message -----
From: "James Duncan Davidson" <du...@x180.net>
To: <an...@jakarta.apache.org>
Sent: Thursday, January 04, 2001 9:24 PM
Subject: Re: [PATCH] Wait and Available (Updated)
> In the TaskAction abstract base class would be a bit of functionality
> provided for the setting of a 'thread="true|false"' attribute on any
task.
> What this would mean is that when Ant executed a task calling the execute
> method on the TaskAction implementation, the abstract class functionality
> would look to see if the 'thread' property had been set. If it had been,
it
> would spawn a thread, start execution of the TaskAction in it, and the
> return control. When it started execution in a thread, it would register
> that thread on a Scoreboard (and of course the proper thing is to have
the
> thread pull itself off the scoreboard when it is done).
>
I'm pretty comfortable with this since it is pretty much in line with my
original multithreading patch. For the "scoreboard" I just used a vector of
threads. The join task simply did a thread.join() on each thread until the
vector was exhausted whereupon the join task would continue. The task
thread themselves were unaware of the scoreboard and I think that is as it
should be.
> Example:
>
> <target name="main" depends="foo">
> <javac srcdir="src/main" destdir="classes" thread="yes"/>
> <javac srcdir="src/util" destdir="util-classes" thread="yes"/>
> <join/>
> </target>
>
> A core task would also be provided which would be effectively the "join".
It
> would check on the scoreboard until it cleared out, at which time it
would
> release the main thread to move on. Also, end of target should probably
> imply a join -- at least of any threads spawned in that target.
Yep, I believe the implicit join is required. In fact my join task simply
activated the thread joining code present in the Target object, for the end
of target join.
There is one thing which I tried to consider, although not that well, and
that is when an exception in thrown in one or more of the tasks. The
TaskThread object I used to wrap a task in a thread would catch any
exception thrown by the thread and store it. The join code would then query
the TaskThread after the join operation and if an exception had been stored
it would then rethrow it. The only problem was that I didn't then wait for
the other threads to join :-) It would be simple to fix.
>
> This works all well except that Tasks that are checking the Object Model
> might have things change on them. As well, they might want to wait until
> thing are guaranteed stable (probably especially true of scripts). Part
of
> that might mean putting a "wait" call on the Object Model which would
block
> any threads entering that call unless/until the Scoreboard was clear.
>
The other problem would be other shared resources of which System.out is
perhaps one of the most difficult to deal with. Currently some tasks, such
as <java> are able to specify that the output is redirected to a file. If
the java task is not forked, then System.out for the whole ant VM is
redirected to the file. In a single threaded model that is cool, but a
multithreaded model that could lead to some curious output being
redirected. There may also be problems undoing the redirection.
This flows into the GUI too since the concept of System.out and how it is
handled in the GUI need to be thought about too.
> So, that introduces complexity, but if we are going to support MT so that
> you can max out your 8 processor MP boxen like some of my coworkers
really
> want to do, this seems the best way that I can think of to do it with a
> minimum of impact to the build file syntax and maximum effectiveness of
> multithreading any tasks. It *does* mean that Tasks have to be written
like
> Servlets and other MT beasts -- thread hot.
>
> I dunno whether it's worth it to make Task writer's life harder for
> potential MT/MP benefits. It might be... I'm really kinda neutral and
will
> follow the crowd on this one. But this topic has come up enough, and I
> didn't really like breaking the threading block into a sub element
grouping,
> that I dove in to take a thought. Comments?
>
I've never viewed MT in ant as a build performance issue - more the ability
to do two things at once in a single build where those two things will
typically be to run a server and run a junit test harness. BTW, when you
try and do this you realize that you need a sleep task (or wait, perhaps)
too, or some way of allowing the server to come up and knowing it has come
up. Multiple ants is what I do today for this and it is OK but a single
build, supporting "test often" would be nice.
Conor
Re: [PATCH] Wait and Available (Updated)
Posted by James Duncan Davidson <du...@x180.net>.
On 1/3/01 5:09 AM, "Conor MacNeill" <co...@cognet.com.au> wrote:
> He probably can't "wait" till that is "available".
Oh boy.. :)
So, I didn't get the work done on that. A couple of friends came over an
watched Sopranos and we talked about all sorts of blue sky stuff. Oops. :)
What follows is the gist of what I was thinking until I get the HTML posted.
Consider it the "join" that Tom suggested. :) :) :)
Assume Object Model tree contains Target--*Task objects that are mutable
proxys. The actual implementations of Tasks are TaskAction implementations.
I'm playing with the word TaskAction right now since it's what takes Action
and may be more explicit than TaskImpl.
In the TaskAction abstract base class would be a bit of functionality
provided for the setting of a 'thread="true|false"' attribute on any task.
What this would mean is that when Ant executed a task calling the execute
method on the TaskAction implementation, the abstract class functionality
would look to see if the 'thread' property had been set. If it had been, it
would spawn a thread, start execution of the TaskAction in it, and the
return control. When it started execution in a thread, it would register
that thread on a Scoreboard (and of course the proper thing is to have the
thread pull itself off the scoreboard when it is done).
Example:
<target name="main" depends="foo">
<javac srcdir="src/main" destdir="classes" thread="yes"/>
<javac srcdir="src/util" destdir="util-classes" thread="yes"/>
<join/>
</target>
A core task would also be provided which would be effectively the "join". It
would check on the scoreboard until it cleared out, at which time it would
release the main thread to move on. Also, end of target should probably
imply a join -- at least of any threads spawned in that target.
This works all well except that Tasks that are checking the Object Model
might have things change on them. As well, they might want to wait until
thing are guaranteed stable (probably especially true of scripts). Part of
that might mean putting a "wait" call on the Object Model which would block
any threads entering that call unless/until the Scoreboard was clear.
So, that introduces complexity, but if we are going to support MT so that
you can max out your 8 processor MP boxen like some of my coworkers really
want to do, this seems the best way that I can think of to do it with a
minimum of impact to the build file syntax and maximum effectiveness of
multithreading any tasks. It *does* mean that Tasks have to be written like
Servlets and other MT beasts -- thread hot.
I dunno whether it's worth it to make Task writer's life harder for
potential MT/MP benefits. It might be... I'm really kinda neutral and will
follow the crowd on this one. But this topic has come up enough, and I
didn't really like breaking the threading block into a sub element grouping,
that I dove in to take a thought. Comments?
--
James Duncan Davidson duncan@x180.net
!try; do()
Re: [PATCH] Wait and Available (Updated)
Posted by Conor MacNeill <co...@cognet.com.au>.
From: "James Duncan Davidson" <du...@x180.net>
> On 1/2/01 4:39 AM, "Thomas Christen" <ch...@active.ch> wrote:
> > Hopfully this sounds not impatient,
> >
> > I'd like to ask if there is anybody intersted in my two
> > enhancements/extension
> > (http://marc.theaimsgroup.com/?l=ant-dev&m=97587019310230&w=2) or
should I
> > stop asking ?
>
> Actually, in the next draft of the Ant 2.0 proposal that I'll get up
tonight
> (assuming I don't fall asleep like I did last night :) is a take on
> multithreading of tasks as part of the base Ant engine in an easy and
native
> way that adds very little overhead to the antfile syntax.
>
He probably can't "wait" till that is "available".
Sorry, terrible joke - couldn't resist.
Re: [PATCH] Wait and Available (Updated)
Posted by James Duncan Davidson <du...@x180.net>.
On 1/2/01 4:39 AM, "Thomas Christen" <ch...@active.ch> wrote:
> Hopfully this sounds not impatient,
>
> I'd like to ask if there is anybody intersted in my two
> enhancements/extension
> (http://marc.theaimsgroup.com/?l=ant-dev&m=97587019310230&w=2) or should I
> stop asking ?
Actually, in the next draft of the Ant 2.0 proposal that I'll get up tonight
(assuming I don't fall asleep like I did last night :) is a take on
multithreading of tasks as part of the base Ant engine in an easy and native
way that adds very little overhead to the antfile syntax.
--
James Duncan Davidson duncan@x180.net
!try; do()
RE: [PATCH] Wait and Available (Updated)
Posted by Thomas Christen <ch...@active.ch>.
Hopfully this sounds not impatient,
I'd like to ask if there is anybody intersted in my two
enhancements/extension
(http://marc.theaimsgroup.com/?l=ant-dev&m=97587019310230&w=2) or should I
stop asking ?
The problem I have, the 'Parallel' Task is nearly finished. But I had to add
some code to other classes and base on the functionality of the above
mentioned Tasks. For me its anoying - always try to keep my localy enhanced
classes in synch with the repository.
Thomas
RE: [PATCH] Wait and Available (Updated)
Posted by Thomas Christen <ch...@active.ch>.
The first time I posted the new task <wait> and the update on <available> it
caused at lot of reactions.
Since I reposted the 'improved' Version - no reaction
(http://marc.theaimsgroup.com/?l=ant-dev&m=97587019310230&w=2). Therfore I'd
like to ask if anyone has had the chance to look at it ?
Thomas