Mailing-List: contact ant-dev-help@jakarta.apache.org; run by ezmlm
From: "Conor MacNeill" <conor@m64.com>
To: <ant-dev@jakarta.apache.org>
Subject: RE: [PATCH] multithreading tasks
Date: Sun, 18 Jun 2000 22:26:57 +1000
Message-ID: <000c01bfd920$7e80bbd0$80dc1fcb@cognet.com.au>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
In-Reply-To: <B571703B.47F0%james.davidson@eng.sun.com>
Importance: Normal

Duncan,

> From: James Duncan Davidson [mailto:james.davidson@eng.sun.com]
>
> Has this been committed? I didn't see a commit message go out on
> it. In any
> case I'm -1 on this.

No, this has not been committed yet. Let me see if I can "work" on you to
see whether it is a good idea or not? Let me try to address each of your
issues ...

> MT programming isn't *that* easy and ...

I agree in general that MT can have pitfalls. I have less of a problem,
however, with multithreading Ant tasks. If Ant tasks are run concurrently
they will have minimal interaction with each other within Ant. Such
interaction would be through the Project ant Target objects and, in
practice, most tasks do not use those objects extensively. The potential for
interaction outside of Ant (through the file system, for example) is there,
I guess, but again I don't see it as problematic. If there are such
interactions, the tasks should be run sequentially.

> I don't really think that projects should deal with it.

OK. I think there are two cases. Within a target, there may be some tasks
which are independent. Those independent tasks could be executed
concurrently. In this situation, concurrent operation is not essential but
could be useful for performance reasons. An example might be where it is
necessary to download code from two independent CVS repositories. Another
example might be to execute a set of ant subprojects in parallel to build a
set of, independent, jars.

In the other cases, two tasks MUST be executed concurrently because of their
interaction, external to Ant. Because of this interaction, they cannot be
executed sequentially. An example would be running a test client against a
server. This is my particular situation. I am running a JUnit test harness
against a Weblogic EJB container. I can do this outside of Ant, of course,
but I really like the integration of the testing step with the build step.
Its part of the "test often" philosophy and I don't have to remember to run
the tests. If I make it part of the CVS check-in process then it is even
better.

>
> If concurency is needed for testing, then doing a test that that performs
> it's own parallelism at that level is fine, ...

I am not interested in parallelising the tests themselves, if that is what
you mean. I merely need to run the test system at the same time as the
system being tested. These are both standard tasks (I run both as <java>
tasks). If I have to combine these tasks to get the necessary parallelism
happening inside a taskdef, that task would not be useful or reusable. How
many people could use a <WeblogicWithJUnitTest> task? The components are
there in Ant and I want to put them together in a parallel fashion at the
build.xml level and not within a taskdef.

> but building parallelism into Ant gets probelmatic fast.

Why? Perhaps you could expand on the likely problems? I have been using
parallel tasks now for a while. There is no interaction between the tasks
within Ant. The external interaction is well defined and interesting :-)

I understand that simplicity is the Ant motto and the inclusion of this
feature provides a power which could be misused. Nevertheless, on some
occasions I feel that power is needed. It is off by default which means it
requires definite thought to turn it on (OK, maybe not much thought :-)

>
> > Let me know what you think. If this is accepted, I plan two new small
> > taskdefs:- a sleep task and a join task.
>
> Problem here is that now you are using tasks not to perform functionality,
> but as logical control.

OK. Fair point. I perform an implicit join at the end of a target so the
join task could be left out and the same effect achieved by target
dependency relationships. My motivation was to be able to bring the threads
back together within the single target and then continue sequentially.
Creating a whole set of targets and dependencies seemed to reduce the
cohesiveness of the targets.

Sleep is really a simple form of task coordination so I can see your
objection. Nevertheless, I have found it useful, since weblogic takes a
while to start up and deploy EJBs. I have to wait for that to happen before
I start my JUnit test harness. I didn't want any more complicated task
coordination so sleep suffices.

> Expressing threading semantics in the XML is neat, but complicates
> things to a great degree.
>

Why?

> I understand the motive -- parallelism on tests is a good thing,
> but I don't
> see why that functionality has to be genericized to this level.
>

OK, I've made my arguments. Perhaps you and others can comment?

Cheers

Conor