Stefan,
From: "Stefan Bodewig" <[EMAIL PROTECTED]>
>
> So let me chip in, even if I don't have a very strong opinion on it
> either.
>
> To me it's quite clear that asking, whether a TaskContainer concept
> (I'd prefer that name as well) is desirable, boils down to "Do we want
> to make it easier to write a foreach or a switch/case task?".
>
Lets look, instead, at Thomas' motivation for the TaskContainer -
multithreading of tasks. I certainly support this concept and, although he
was initially against it, so did Duncan. Duncan's approach and my approach
were functionally similar, so I will treat them together. Our proposals
basically allow a build writer to specify that a task is to be run in a
separate thread. It is a pretty primitive approach and the build file
structure does not reflect the threading structure, making the
multithreaded nature of the build less obvious. For example, contrast
<target name="blah"/>
<foo name="foo1">
<bar name="bar1">
<foo name=:"foo2" thread="yes"/>
<bar name="bar2" thread="yes"/>
<join>
</target>
with
<target name="blah"/>
<foo name="foo1">
<bar name="bar1">
<parallel>
<foo name=:"foo2"/>
<bar name="bar2"/>
</parallel>
</target>
I like the latter approach. It separates the threading control from the
tasks, makes the threading obvious in the build file structure and makes
the "join" point obvious.
Now both Duncan and I arrived at the need for multithreading from different
directions. My motivation was for testing of servers, whilst Duncan, if I
understood correctly, was interested in better utilisation of system
resources during a build, particularly on multiprocessor machines. Thomas
has also arrived at the need for multithreading so I think it is a definite
requirement.
Now let me ask some questions:
Do we want to support multithreading?
Do we want the more expressive form, as proposed by Thomas.
I would say yes to both these questions. If we agree, we need to decide on
the mechanism by which we provide that facility. Do we make <parallel> a
special tag recognized by projectHelper? I think we would still have the
TaskContainer interface but it would not be available to other tasks. The
Parallel class would not extend Task and both Parallel and Target would
implement TaskContainer. Doing this would control what could be a
TaskContainer but would make <parallel> part of the core as much as
<project> and <target>.
The question has become whether we want to allow for generalized task
composition, available to all tasks or to limit task composition to two
situations (targets and parallel threads), the knowledge of which is
embedded in the core.
Thoughts?
BTW, I know the general policy is to seek forgiveness rather than
permission. In this case, however, I have asked Thomas to rework his
patches somewhat and I think it is only fair to him that we decide on the
concept before he goes ahead with that..
Conor
