ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From James Duncan Davidson <dun...@x180.net>
Subject Re: [PATCH] Wait and Available (Updated)
Date Fri, 05 Jan 2001 20:26:25 GMT
On 1/4/01 6:29 AM, "Conor MacNeill" <conor@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()


Mime
View raw message