ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Steve Loughran" <stev...@iseran.com>
Subject Re: cvs commit: jakarta-ant/src/testcases/org/apache/tools/ant/taskdefs ExecuteJavaTest.java TimeProcess.java ExecuteWatchdogTest.java
Date Fri, 05 Apr 2002 17:52:28 GMT

----- Original Message -----
From: "Stefan Bodewig" <bodewig@apache.org>
To: <ant-dev@jakarta.apache.org>
Sent: Friday, April 05, 2002 5:28 AM
Subject: Re: cvs commit:
jakarta-ant/src/testcases/org/apache/tools/ant/taskdefs ExecuteJavaTest.java
TimeProcess.java ExecuteWatchdogTest.java


> On 5 Apr 2002, <bodewig@apache.org> wrote:
>
> >   timeout support for <java>
>
> This has a couple of side effects that I want your opinion on before I
> close the bug.
>
> timeout for forked java has been trivial, but I had to change
> ExecuteJava considerably to add it for the in-VM mode.
>
> The main change is that Ant will now run the class in a separate
> thread, if a timeout value has been specified.  I'm not sure whether
> our log system can deal with it (it may receive output from a thread
> that is not associated with a task).
>
> If timeout has been triggered, all ExecuteJava does right now is to
> interrupt() the spawned thread - which means it will not do too much
> for run-away threads.  stop() or even destroy() look more than a
> little dangerous in this context.
>
> But then again, run-away threads without this timeout feature would
> make Ant hang anyway.

I remember looking at this problem a while back, and concluding that using
stop() timeouts on in VM execution is too dangerous; it can affect the
underlying stability of the system too much.

How about making timeout only valid when forked?


--
To unsubscribe, e-mail:   <mailto:ant-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:ant-dev-help@jakarta.apache.org>


Mime
View raw message