ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Donald <>
Subject Re: [PATCH] Asynchronous execution of processes
Date Fri, 09 Nov 2001 10:54:35 GMT
On Fri, 9 Nov 2001 21:44, Jose Alberto Fernandez wrote:
> > > If the test get stuck, then the server will be terminated after the
> > > timeout which should make any further stuff to finish and fail.
> > > Granted, this does not cover all cases but you can see it may be
> > > useful.
> >
> > having no idea on feasability of this. I would like to see four tasks.
> > These would be
> >
> > start (ie async exec kickstart)
> > stop (ask process to shutdown nicely)
> This task is really command dependent. You need to know that "apache -stop"
> shuts down your server, for example. So to me this is just a regular <exec>
> or what have you, up to the user.

not necessarily. On *nix I can go 

kill 1234
killall foo

where my process is #1234 or named foo. This will send a quit or interupt 
signal which will usually kill of a process gracefully (unless they choose to 
ignore it or fail to shutodwn gracefully).

"kill -9 1234" is the kill with extreme predjudice that doesn't give the 
process a chance to do anything before exiting. And it is equivelent to what 
I describe as kill below.

> > join (wait till other process shutsdown)
> You can obtain this support today by using <parallel> and "detach='false'".
> <parallel> will do the thread join for you and the end of <parallel>.

but that requires that everything has to exist inside the parrallel task 
which is not always possible. We would end up having to use antcall hack 
which breaks out of DAG.

> > kill (kill the process imediately)
> I thought about implementing something for this by doing the following:
>     <exec ... id="runamoc.process" />
>     ....
>     <kill processid="runamoc.process" />
> in the current implementation, what we need to do is to keep track of the
> watchdog objects associated with the process and make then kill the
> processes as they do today in a timeout. Notice the use of plural here
> since you may have executed the same <task> multiple times and hence have
> several instances.


> > I have suspicions that this will not be possible from pure java but I
> > figured I would throw this out there to see if anyone else has any good
> > ideas on how to implement this ;)
> This still keeps open the problem of what to do when the build fails in the
> middle between the <exec> and <stop> or <kill>. What is one suppose
to do.
> It seem one needs a way to catch the failure and execute some accion. And
> this brings back the eternal discussion on whether "onerror='errortarget'"
> is too scripty or should a <catch> or <finally> be best.
> And what do we do with the original failure, should it continue to
> propagate so that we know the build failed (good for tests) or should we
> assume the build was reapired by this action and succeeds (this is what
> <junit hatlonfailure="false">; does).

punt the issue. Not going to be easily dealt with in Ant1 so we ignore it for 
now and try to fix it in Ant2.



 We shall not cease from exploration, and the 
  end of all our exploring will be to arrive 
 where we started and know the place for the 
        first time -- T.S. Eliot

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

View raw message