I simply can't belive it ! Is it true what I'm reading ? >From my experiance I can tell you it works fine. In fact, our Production depends on this concept a runs a lot of jobs depneding on those tasks submitted by my self earlier. Since the discussion/opinions went in other directions a gave up synchronizing my extensions with std ant 1.3 but if it would help I could have a look und try to find out what in the end needed to be fixed in ant 1.3 to make it real working (e.g. antcall etc.).
regards Thomas Christen > -----Urspr�ngliche Nachricht----- > Von: Conor MacNeill [mailto:[EMAIL PROTECTED] > Gesendet am: Sonntag, 22. Juli 2001 15:48 > An: [EMAIL PROTECTED] > Betreff: Introduction of Multithreading > > I have just committed a major change to support multithreading of tasks > within Ant. It is based on the patch, originally submitted by Thomas > Christen in January. It consists of three major components > > 1. Task Containers > > I have introduced the concept of a TaskContainer. This is an interface. An > object implementing this interface can have Tasks added to it. The target > object implements this interface. If a task implements this interface, it > may contain other tasks. This is a general facility which has > been used for > the multithreading support but it can be used (abused) for other task > composition applications > > 2. New Tasks - <parallel> and <sequential> > > These two new tasks implement the TaskContainer interface. The <parallel> > task allows tasks to be executed in multiple threads - currently > one thread > per contained task. The <sequential> task just executes tasks in sequence > and is only of use within <parallel>. An example usage might be > <target name="code"> > <parallel> > <sequential> > <mkdir dir="classes1"/> > <javac taskname="javac src1" srcdir="src1" destdir="classes1"> > </javac> > </sequential> > <sequential> > <mkdir dir="classes2"/> > <javac taskname="javac src2" srcdir="src2" destdir="classes2"> > </javac> > </sequential> > </parallel> > </target> > > 3. System.out Management > > Previously many tasks would redirect System.out and System.err to capture > the output of a command. That is not workable in a multithreaded > environment. I have changed all System.out management. The Main class now > sets up a DemuxOutputStream to handle ALL system.out use by tasks. The > DemuxOutputStream (based on LogOutputStream, which I think is not used > anymore), collects output based on the thread that generated the > output. It > then forwards output to the project instance. The project object tracks > which tasks are running on which threads and forwards the output to the > appropriate task. By default the output is just logged but this may be > overridden by individual tasks. The Java task, for example, will divert > such output into the output file if it is specified. > > One side effect of this change is that non-forked <java> output which uses > System.out now looks exactly the same as output from a forked <java> > command. That is probably a good thing. This should also be good for GUIs, > such as Antidote, and IDEs since all output now comes through Ant build > events rather than scribbling on System.out. > > Things to Do > =========== > I'm about to investigate the impact on <ant> and <antcall>. There may need > to be some adjustments. I thought I'd get this out there to see if anyone > has issues with it before I go much further. > > Conor > >
