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 ... etc 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. -- Cheers, Peter Donald -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
