ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Donald <>
Subject Re: Introduction of Multithreading
Date Sun, 22 Jul 2001 14:13:11 GMT

I have issues with this - but you knew that right ? ;)

Three things. I really don't like the TaskContainer interface because it is 
completely incompatible with Ant2s notion of task proxys. It also would 
produce surprising results if people were expecting properties to behave the 
same as they do elsewhere in the build file. I think it is an extremely bad 
idea to have different scoping rules inside containers from everywhere else.

Two I can not see the need for sequential at all as similar functionality 
exists with antcall and that matches the rest of ants behaviour.

Three there is zero serialization of events when transmitted between 
contained tasks. So messages could appear to come be logged as coming from 
one task but coming from a completely separate one.

four. The DemuxOutputStream requires a complicated set of tranisitions. ie 
stream calls project which calls task which calls project which calls ... 
etc. The task shouldn't know or care about the logging event and it should go 
straight from DemuxOutputStream to the listener (or at least to the listener 

Okay four complaints really ;)

On Sun, 22 Jul 2001 23:47, Conor MacNeill wrote:
> 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



| "Faced with the choice between changing one's mind, |
| and proving that there is no need to do so - almost |
| everyone gets busy on the proof."                   |
|              - John Kenneth Galbraith               |

View raw message