ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Conor MacNeill" <>
Subject RE: Introduction of Multithreading
Date Mon, 23 Jul 2001 00:15:47 GMT
> 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

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

Don't know what you are getting at here.

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

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

> four. The DemuxOutputStream requires a complicated set of
> tranisitions. ie
> stream calls project which calls task which calls project which calls ...
> etc.

Lets finish that. stream calls project. Project determines which task is
active on the thread and forwards the message to the task which then
performs its normal logging function. That logging function is: task calls
project which sends the event. That is it. There may be a refactor
opportunity to remove the project from the event management (i.e. task sends
event) but I haven't looked at that yet.

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.

> Okay four complaints really ;)

Who is counting :-)


View raw message