You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ant.apache.org by Conor MacNeill <co...@cortexebusiness.com.au> on 2001/07/22 15:47:33 UTC
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
Re: Introduction of Multithreading
Posted by Stefan Bodewig <bo...@apache.org>.
On Wed, 25 Jul 2001, Conor MacNeill <co...@cortexebusiness.com.au>
wrote:
> From: "Stefan Bodewig" <bo...@apache.org>
>> What problems do you see with allowing arbitrary other child
>> elements as well?
>
> I was worried about the impact on the use of UnknownElements.
I see.
> There is no loss of capability as nested elements can themselves be
> TaskContainers. So, you can have a list of tasks in one nested
> element and other nested elements for other things
I can live with that - it might make some tasks look a little silly,
but that's OK.
> I see now, however, that you will not be able to taskdef
> TaskContainer Tasks since the UnknownElement will not be a
> TaskContainer. I guess RuntimeConfigurable.maybeConfigure will pick
> up the task container.
I'll give it a second look.
Stefan
Re: Introduction of Multithreading
Posted by Conor MacNeill <co...@cortexebusiness.com.au>.
----- Original Message -----
From: "Stefan Bodewig" <bo...@apache.org>
To: <an...@jakarta.apache.org>
Sent: Wednesday, July 25, 2001 7:44 PM
Subject: Re: Introduction of Multithreading
> On Sun, 22 Jul 2001, Conor MacNeill <co...@cortexebusiness.com.au>
> wrote:
>
> > I have introduced the concept of a TaskContainer. This is an
> > interface. An object implementing this interface can have Tasks
> > added to it.
>
> Yes, but nothing else. Why?
>
> What problems do you see with allowing arbitrary other child elements
> as well? I mean apart from making TaskHandler.startTag a little ugly.
I was worried about the impact on the use of UnknownElements. If you look
at the code in TaskHandler.init, it is possible for a task handler to be
invoked even when a Task is not yet defined. So there is no easy way to
make the decision at that time about whether a particular nested element is
a task or nested element. The alternative, to try a nested element also
looked complex in the face of Unknown elements. I figured it was best to
make the decision early. There is no loss of capability as nested elements
can themselves be TaskContainers. So, you can have a list of tasks in one
nested element and other nested elements for other things
<foo>
<tasks>
<echo>
<javac>
</tasks>
<classpath ...>
</foo>
I see now, however, that you will not be able to taskdef TaskContainer
Tasks since the UnknownElement will not be a TaskContainer. I guess
RuntimeConfigurable.maybeConfigure will pick up the task container.
So, as you know this code quite well, I'd be interested to know your
thoughts on whether we should change it.
Conor
Re: Introduction of Multithreading
Posted by Stefan Bodewig <bo...@apache.org>.
On Sun, 22 Jul 2001, Conor MacNeill <co...@cortexebusiness.com.au>
wrote:
> I have introduced the concept of a TaskContainer. This is an
> interface. An object implementing this interface can have Tasks
> added to it.
Yes, but nothing else. Why?
What problems do you see with allowing arbitrary other child elements
as well? I mean apart from making TaskHandler.startTag a little ugly.
Stefan
Re: Introduction of Multithreading
Posted by Stefan Bodewig <bo...@apache.org>.
On Sun, 22 Jul 2001, Conor MacNeill <co...@cortexebusiness.com.au>
wrote:
> The Main class now sets up a DemuxOutputStream to handle ALL
> system.out use by tasks.
DemuxOutputStream uses the same (broken) logic to assemble lines to
send to the logging system - we should get rid of this and use
line.separator instead (the current system breaks - like most other
things - on OS/390 which doesn't use either \r nor \n as line
separator).
> (based on LogOutputStream, which I think is not used anymore),
There still are LogOutputStreamHandlers that use it in <java>, <exec>
and probably other places.
> Things to Do
Adapt the loggers to work in the context of parallel tasks.
I'll look into it tomorrow.
Stefan
Re: Introduction of Multithreading
Posted by Peter Donald <do...@apache.org>.
On Wed, 25 Jul 2001 00:48, Stefan Bodewig wrote:
> On Mon, 23 Jul 2001, Peter Donald <do...@apache.org> wrote:
> > It also would produce surprising results if people were expecting
> > properties to behave the same as they do elsewhere in the build
> > file.
>
> I must be missing something here, aren't properties behaving exactly
> the same as they do everywhere else in the build file?
>
> The first property task wins (but you cannot be sure, which one may be
> the first, of course). Properties defined outside are available in
> the container and vice versa. In what way are they different?
My test file terned out to have a typo and so I assumed that properties where
set are parse time for subelements - but I guess I was wrong ;)
Cheers,
Pete
*-----------------------------------------------------*
| "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 |
*-----------------------------------------------------*
Re: Introduction of Multithreading
Posted by Stefan Bodewig <bo...@apache.org>.
On Mon, 23 Jul 2001, Peter Donald <do...@apache.org> wrote:
> It also would produce surprising results if people were expecting
> properties to behave the same as they do elsewhere in the build
> file.
I must be missing something here, aren't properties behaving exactly
the same as they do everywhere else in the build file?
The first property task wins (but you cannot be sure, which one may be
the first, of course). Properties defined outside are available in
the container and vice versa. In what way are they different?
> I think it is an extremely bad idea to have different scoping rules
> inside containers from everywhere else.
I agree completely - but we'll have to talk about scoping rules in the
light of Ant2 (once again 8-).
Stefan
Re: Introduction of Multithreading
Posted by Peter Donald <do...@apache.org>.
On Wed, 25 Jul 2001 01:37, Stefan Bodewig wrote:
> On Wed, 25 Jul 2001, Peter Donald <do...@apache.org> wrote:
> > Kewl .. now we just gotta find a nice way of dealing with standard
> > input ;)
>
> Patch to deal with it in the context of PumpStreamHandler has been
> sent to this list yesterday. This should make it work for <exec> and
> <java>, I haven't looked at it at all though.
>
> But I guess this is not what you are talking about.
well what I was talking about is my halfbaked ideas about redirection. One
thing that makes the command line so powerful is you can join together
commads via pipes or whatever. So what I guess I was thinking about was how
to I attach the output of task 1 to task 2's stdin. Trying to figure out a
clean way of doing it is damn hard ;)
Anyways it is not something that we should think about now because there has
only been a few times that people have asked for that sorta functionality.
> Interesting question is, which task should get to read from standard
> input if several tasks run in parallel ... Maybe all of them?
no idea ;)
> Providing input to tasks is a different beast in that you may want to
> have the GUI pop up a dialog to ask for input instead of falling back
> to standard input.
yup
Cheers,
Pete
*-----------------------------------------------------*
| "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 |
*-----------------------------------------------------*
Re: Introduction of Multithreading
Posted by Conor MacNeill <co...@cortexebusiness.com.au>.
----- Original Message -----
From: "Stefan Bodewig" <bo...@apache.org>
>
> Interesting question is, which task should get to read from standard
> input if several tasks run in parallel ... Maybe all of them?
>
> Providing input to tasks is a different beast in that you may want to
> have the GUI pop up a dialog to ask for input instead of falling back
> to standard input.
>
What I had thought of in mutant was a InputProvider interface. It was
really only designed for <prompt> style input, which I think wouldn't be a
bad start. Different front ends could provide different InputProviders, so
that some task isn't trying to read from System.In when running Ant as part
of a GUI. I thought of a few providers
UnattendedInputProvider - just returns with no input
CommandLineInputProvider - basic read from System.in
DialogInputProvider - AWT dialog
etc, etc
The CommandLine version would be synchronized so that multiple threads
would queue up to get input.
A general demuxInputStream sitting on System.in might send out to this
input provider.
Anyway, just thoughts at this stage.
Conor
Re: Introduction of Multithreading
Posted by Stefan Bodewig <bo...@apache.org>.
On Wed, 25 Jul 2001, Peter Donald <do...@apache.org> wrote:
> Kewl .. now we just gotta find a nice way of dealing with standard
> input ;)
Patch to deal with it in the context of PumpStreamHandler has been
sent to this list yesterday. This should make it work for <exec> and
<java>, I haven't looked at it at all though.
But I guess this is not what you are talking about.
Interesting question is, which task should get to read from standard
input if several tasks run in parallel ... Maybe all of them?
Providing input to tasks is a different beast in that you may want to
have the GUI pop up a dialog to ask for input instead of falling back
to standard input.
Stefan
Re: Introduction of Multithreading
Posted by Peter Donald <do...@apache.org>.
On Wed, 25 Jul 2001 00:57, Stefan Bodewig wrote:
> > I see ant2 as having subloggers for stdout and stderr. So if a task
> > wanted to massage its output (like junit task or whatever) it could
> > just register a listener at correct location in logger
> > hierarchy.
>
> And prevent output from going to the default logger as well or send it
> there in addition to the task specific logging?
Both are possible. By default both LogKit and Log4j will inherit parents
output destination unless explicitly set. If you explicitly set them then it
overides.
However both toolkits allow possibility of of adding an extra listener for
output (Log4j directly by additivity and LogKit indirectly by giving access
to LogTarget array).
> I've split feelings about replacing default loggers - as some tasks do
> in effect right now. Of course, the tasks that do it ATM, do so on
> user request (out parameters or the formatter stuff in the junit
> task).
>
> An approach like this could also be used as an aspect that replaces
> the the out attributes of <java> and <exec>, yes, I think I like it as
> well.
Kewl .. now we just gotta find a nice way of dealing with standard input ;)
Cheers,
Pete
*-----------------------------------------------------*
| "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 |
*-----------------------------------------------------*
Re: Introduction of Multithreading
Posted by Stefan Bodewig <bo...@apache.org>.
On Wed, 25 Jul 2001, Peter Donald <do...@apache.org> wrote:
> On Wed, 25 Jul 2001 00:13, Stefan Bodewig wrote:
> And I have come to the conclusion that I HATE antcall now so ... ;)
Welcome to the club 8-)
> I see ant2 as having subloggers for stdout and stderr. So if a task
> wanted to massage its output (like junit task or whatever) it could
> just register a listener at correct location in logger
> hierarchy.
And prevent output from going to the default logger as well or send it
there in addition to the task specific logging?
I've split feelings about replacing default loggers - as some tasks do
in effect right now. Of course, the tasks that do it ATM, do so on
user request (out parameters or the formatter stuff in the junit
task).
An approach like this could also be used as an aspect that replaces
the the out attributes of <java> and <exec>, yes, I think I like it as
well.
Stefan
Re: Introduction of Multithreading
Posted by Peter Donald <do...@apache.org>.
On Wed, 25 Jul 2001 00:13, Stefan Bodewig wrote:
> >> 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 ;)
>
> You cannot completely compare them, as breaking a conditional task
> into three targets may be unnecessarily complex, but it is not
> heavyweight - oppose that with current antcall.
>
> As long as antcall is not the lightweight operation we expect it to
> become in Ant2, there is room for <sequential> IMHO.
>
> > I just think we should stick to existing patterns instead of
> > introducing more variability.
>
> Agreed, but ... see above.
I guess. And I have come to the conclusion that I HATE antcall now so ... ;)
> > 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.
>
> OK, so it is a documentation issue, as well as a question of adapting
> the listeners that ship with Ant, right?
> > Ouch - theres the rub - Also a great place to have a child
> > logger/category ;)
>
> A great place to have hierarchical TaskContexts 8-)
That too ... IIRC I added that to myrmidon a bit ago. But that is othogonal
to loggin hierarchy. I see ant2 as having subloggers for stdout and
stderr. So if a task wanted to massage its output (like junit task or
whatever) it could just register a listener at correct location in logger
hierarchy. Like that ? I do ;)
Cheers,
Pete
*-----------------------------------------------------*
| "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 |
*-----------------------------------------------------*
Re: Introduction of Multithreading
Posted by Stefan Bodewig <bo...@apache.org>.
Tackling the thread from its last message ...
On Mon, 23 Jul 2001, Peter Donald <do...@apache.org> wrote:
> On Mon, 23 Jul 2001 10:15, Conor MacNeill wrote:
>> > From: Peter Donald [mailto:donaldp@apache.org]
>> > Two I can not see the need for sequential at all as similar
>> > functionality exists with antcall
>>
>> 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 ;)
You cannot completely compare them, as breaking a conditional task
into three targets may be unnecessarily complex, but it is not
heavyweight - oppose that with current antcall.
As long as antcall is not the lightweight operation we expect it to
become in Ant2, there is room for <sequential> IMHO.
> I just think we should stick to existing patterns instead of
> introducing more variability.
Agreed, but ... see above.
> 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.
OK, so it is a documentation issue, as well as a question of adapting
the listeners that ship with Ant, right?
> Ouch - theres the rub - Also a great place to have a child
> logger/category ;)
A great place to have hierarchical TaskContexts 8-)
Stefan
Re: Introduction of Multithreading
Posted by Peter Donald <do...@apache.org>.
On Mon, 23 Jul 2001 10:15, Conor MacNeill wrote:
> > From: Peter Donald [mailto:donaldp@apache.org]
> >
> > 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
<sequential>
<antcall target="foo"/>
</sequential>
<sequential>
<echo taskname="echo2" message="Some message"/>
</sequential>
</parallel>
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 ;/
Cheers,
Pete
*-----------------------------------------------------*
| "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 |
*-----------------------------------------------------*
Re: Introduction of Multithreading
Posted by Stefan Bodewig <bo...@apache.org>.
On Mon, 23 Jul 2001, Conor MacNeill <co...@cortexebusiness.com.au>
wrote:
>> From: Peter Donald [mailto:donaldp@apache.org]
>
>> Okay four complaints really ;)
>
> Who is counting :-)
>
OK, I'll never do it again. 8-)
Stefan
RE: Introduction of Multithreading
Posted by Conor MacNeill <co...@cortexebusiness.com.au>.
> From: Peter Donald [mailto:donaldp@apache.org]
>
> 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 :-)
Conor
Re: Introduction of Multithreading
Posted by Peter Donald <do...@apache.org>.
Hi,
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
dispatcher).
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
--
Cheers,
Pete
*-----------------------------------------------------*
| "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 |
*-----------------------------------------------------*
AW: Introduction of Multithreading
Posted by Thomas Christen <ch...@active.ch>.
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
>
>