ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jose Alberto Fernandez" <>
Subject Re: [PATCH] Asynchronous execution of processes
Date Fri, 09 Nov 2001 10:44:53 GMT
From: "Peter Donald" <>

> On Fri, 9 Nov 2001 12:54, Jose Alberto Fernandez wrote:
> >
> > As someone suggested we could do something about redirecting IO to a file
> > which it cannot be done today, but taha is only if the user specifies usage
> > of a file.
> Having no idea on the portability of such things but do most OSes have some 
> form of /dev/null which we could open things to? 

I guess my view on this is that is users want redirect to /dev/null they should just
say so on their command. I like to have the ability to get output from the spinned out
process. Of course, the fact that I would pay a price (the process shuts down at the end)
is not necessarily bad. One could have a way to say "nooutput='true'" or something
is you want to send things to the /dev/null equivalent.

> > 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.

> 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>.

> 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).

Jose Alberto

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

View raw message