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