ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Thomas Christen" <>
Subject AW: [PATCH] Wait and Available (Updated)
Date Thu, 04 Jan 2001 20:04:56 GMT
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.

> -----Urspr√ľngliche Nachricht-----
> Von: Conor MacNeill []
> Gesendet am: Donnerstag, 4. Januar 2001 15:30
> An:
> Betreff: Re: [PATCH] Wait and Available (Updated)
> Duncan,
> ----- 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
> 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:
> For additional commands, e-mail:

View raw message