ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Eric Siegerman <>
Subject Re: [RESULT] multithrading
Date Wed, 25 Apr 2001 00:13:18 GMT
On Tue, Apr 24, 2001 at 04:19:45PM -0400, Glenn McAllister wrote:
> <target name="do_many_things" depends="foo,bar,blat">
>   <parallel>
>     <javac ... />  <!-- compile source -->
>     <copy todir="${deploy.dir}" ... />  <!-- copy properties files into the
> tree -->
>   </parallel>
> </target>

NB: I've modified one line in the above quote, since I have
things to say about dependencies; the line originally read:
> <target name="do_many_things" depends="...">

You're thinking in terms of telling ant when two things can be
done in parallel; it's better to think in terms of telling it
when they *can't* be, and letting it default to parallel unless
told otherwise.  Like this:

    <target name="build" depends="compile,copy_properties"/>

    <target name="compile" depends="foo,blat">
	<javac ... />  <!-- compile source -->

    <target name="copy_properties" depends="bar">
	<copy todir="${deploy.dir}" ... />  <!-- copy properties files into the class -->

Looks familiar, no? :-)  Since neither "compile" nor
"copy_properties" depends on the other, ant can do them in
parallel.  *No* additional syntax is required to say that.

> What if one parallel target depends on another?

Then they're not parallel, by definition.  Or rather, parallelism
isn't an attribute of a target (or a task) in the first place;
it's an attribute of the relationship between two of them.

> How do we resolve order?

The "depends" clauses.

Isn't that what "declarativeness" is all about -- let me just
tell you *what* needs to be done, not how (or in this case, when)
to do it?

Note also that with parallel tasks, the "foo,bar,blat" that
"do_many_things" depends on is the union of the dependencies for
both the <javac> and <copy> tasks (and potentially many more).
With parallel targets, each such dependency is explicitly
associated with the task that actually depends on it.  You don't
need a <parallel> kludge to tell ant that the two tasks have no
mutual dependencies, because you've already told it in the
targets' "depends" attributes (by not naming any).

Reentrancy is a separate issue.  If only one copy of a given task
can be running at once (eg. because they share output files, like
old-fashioned yacc implementations in the C world), ant has to
know that.  But it's just another datum used by the scheduler --
probably defined statically in the task's implementing class.

> The concensus seems to be that the complexity involved would override the
> benefit.

The complexity of implementation may well do so; I don't know the
code well enough to say (though it's been done in at least a
few make's).

Complexity of *use*, on the other hand ... well, adding a
<parallel> keyword to express what the syntax can already say
doesn't strike me as making things simpler...


|  | /\
|-_|/  >   Eric Siegerman, Toronto, Ont.
|  |  /
Those who don't understand UNIX are condemned to reinvent it, poorly. 
    - Henry Spencer 

View raw message