ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From James Duncan Davidson <>
Subject Re: [PATCH] Wait and Available (Updated)
Date Thu, 04 Jan 2001 10:24:17 GMT
On 1/3/01 5:09 AM, "Conor MacNeill" <> 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).


    <target name="main" depends="foo">
       <javac srcdir="src/main" destdir="classes" thread="yes"/>
       <javac srcdir="src/util" destdir="util-classes" thread="yes"/>

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                              
                                                                  !try; do()

View raw message