ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "marvin greenberg" <>
Subject Re: [DISC] multithrading
Date Tue, 27 Mar 2001 13:32:38 GMT
----- Original Message ----- 
From: "Stefan Bodewig" <>
To: <>
Sent: Tuesday, 27 March, 2001 7:20 AM
Subject: Re: [DISC] multithrading

> > * Multithreaded execution of tasks within the same target.
> within the same container element +1
> > * Multithreaded execution of targets.
> I fear this would become overly complex.
> Stefan

Actually, supporting multithreading should not be complicated
with different "architecture". Really soon, I'll have to put up or
shut up.  Many of the ideas I'm  supporting were part of the 'frantic'
proposal with some differences.   The ideas  are somewhat
incompatible with some groundrules that have been established,
like not changing Task interface, and I honestly don't have enough
time right now to learn about where all the ideas have evolved since
I last looked at Ant, a few  months ago (Target, e.g.).

So I'm planning to write something, try and justify my ideas, and let
everyone  see what they think.  Because Ant 2.0 is fairly far along,
and I may be way off  base or incompatible with the current
architectural ideas, I think the probable outcome if enough people
like anything I say may be an Ant 2.5 kind of thing.

If nobody likes it, it will be simpler.


Bill Brooks is looking at Prolog, which may bring in some of these
ideas.  Another thing to look at is IDEF-0, and process definition
languages, and maybe stuff from WfMC (Workflow mgmt Coalition).

There is also a new BPML (an XML business process modeling
language) from, which I have not had enough time to
look at.  The point is that there is actually a large body of knowledge
relevant to this problem -- process definition,  some of it harder
to find than others.

----- Original Message ----- 
From: "Matthew Kuperus Heun" <>
To: <>
Sent: Monday, March 26, 2001 1:07 PM
Subject: Re: [DISC] multithrading

> Greetings:
> Example use case:
> We have one target that creates libraries that the rest of our code 
> builds against.  I have a dual-processor machine, and I would LOVE to 
> be able to run subsequent targets (the ones the depend on the 
> libraries) in different threads, thereby utilizing both processors in 
> the build process.

View raw message