ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Thomas Christen" <...@active.ch>
Subject AW: Introduction of Multithreading
Date Wed, 25 Jul 2001 19:20:20 GMT
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:conor@cortexebusiness.com.au]
> Gesendet am: Sonntag, 22. Juli 2001 15:48
> An: ant-dev@jakarta.apache.org
> 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
>
>


Mime
View raw message