ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Donald <>
Subject Re: [myrmidon] TaskListener and friends
Date Sat, 20 Apr 2002 12:05:42 GMT
On Sat, 20 Apr 2002 19:18, Adam Murdoch wrote:
> > Well not sure. I was thinking that it is only really necessary for the
> > Executor to have access to firing mechanisms. It would then call it at
> > start/end of task execution and it would also binf a stream to
> > System.out/err and have that stream redirect output as events.
> Yep, this is better than the workspace firing them.  Would we do away with
> the 'project-started', 'target-started', etc events (since they can be
> implied from the task events)?  

> How would we distinguish between events
> from the same task being executed in different execution frames?

They will either have a different path (if in different target or project), 
different processID (if in same target but running async) or be between 
start/stop events (if running sync).

> How would the input stream deal with async. execution?  Same as ant1?  If
> so we probably want some way for a task to attach whatever extra threads it
> spins up.

Mostly the same except on a larger scale. ie Executor will do stream 
redirection in same way but it will also do things like
* thread ClassLoader hooked up
* redirecting System.getProperty() to per-thread hashmap
* redirecting URLStreamFactory stuff to per-thread factorys
* if tasks opens a gui and does not dispose windows they will be auto disposed
* setup proper thread names
* System.exit() causing a ThreadDeath exception
* permissions made per-thread

ie It achives a minimal sort of Isolation that we can use to achieve things we 
can't in ant1.x. Almost anything that works in same working directory and 
does not load native code will now work as in-JVM threads rather than 
requiiring new JVMs.


Peter Donald

To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message