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 Mon, 23 Jul 2001 02:16:13 GMT
On Mon, 23 Jul 2001 10:15, Conor MacNeill wrote:
> > From: Peter Donald []
> >
> > Hi,
> >
> > I have issues with this - but you knew that right ? ;)
> I thought you might.


> > Three things. I really don't like the TaskContainer interface
> > because it is
> > completely incompatible with Ant2s notion of task proxys.
> Many things in Ant 1.x are incompatible with the concepts of Ant2, I guess.
> I think TaskContainer is a fairly neat solution for Ant 1.x

yup ;)

> > 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.
> Look at the example. Using <sequential> within a <parallel> block is simple
> and effective. Using antcall to achieve the same thing would be heavyweight
> and unnecessarily complex.

Breaking a target into three targets (with if attributes) instead of having a 
single if task is unnecessarily complex - but we still do it ;) I just think 
we should stick to existing patterns instead of introducing more variability.

> > 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.
> This is not true. Each event has the task to which it is related as part of
> the event.

Okay I guess I should be clearer. From the design of listener interface I 
expect event logs to behave like they do in SAX. ie a tasks output occurs 
between start and end task events. And I have written loggers accordingly. If 
you use the information internal to each BuildEvent however it should be 
fine. The problem is not all loggers/listeners do. ie Even defult logger 
breaks with

        <antcall target="foo"/>
        <echo taskname="echo2" message="Some message"/>

It it is possible that echo2 will be logged as belonging to fo target 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
> > dispatcher).
> No, this will not work. Firstly the demux does not send events, it sends
> output. It demuxes it according to thread. Really this was based on your
> suggestion to use ThreadLocals (but they are not supported in Java 1.1).
> The tasks must be involved in deciding whether that output should become a
> logged event (the default action) or processed in some other way. For
> example the <java> task can redirect the output to a file. The junit task
> sends the output to a formatter. These should not be bypassed.

Ouch - theres the rub - Also a great place to have a child logger/category ;)

Hmmmmm. The solutions still feels messy but I can't think of cleaner solution 
without a complete refactoring ;/



| "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