ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Conor MacNeill" <>
Subject Re: [PATCH] Wait and Available (Updated)
Date Thu, 04 Jan 2001 14:29:46 GMT

----- Original Message -----
From: "James Duncan Davidson" <>
To: <>
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
> 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,
> 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
> 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".
> would check on the scoreboard until it cleared out, at which time it
> 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
> that might mean putting a "wait" call on the Object Model which would
> 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
> 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
> 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
> 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
> 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.


View raw message