Duncan, ----- Original Message ----- From: "James Duncan Davidson" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> 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
