ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Bodewig <>
Subject Re: bug #49119, threading and IO
Date Tue, 17 Aug 2010 16:36:47 GMT
On 2010-08-15, Nicolas Lalevée wrote:

> The bug is about a forked <java> stealing characters from the input
> stream even if is finished.  This is due to the pumping thread which
> is reading the Ant own input stream and redirecting it to the the
> process. It doesn't stop at the end of the java task. It is actually
> blocked into the call.

This is also means Ant is leaking threads for every forked process that
has input attached to a stream that is never closed and never provides
input - like - which means Ant leaks threads for every forked
process by default.

This is why I marked bug 49587 as a duplicate of 49119.

> So my first fix [2] was to use the non-blocking feature of
> StreamPumper, relying on inputstream.available() to know if there is
> something to read.

This likely is the only option, yes.  You may need to add the stream
pumper thread to the thread group the complete method in Redirector is
waiting for and make PumpStreamHandler "finish" the input thread (that
it currently isn't even aware of) as well.

> It does fix my issue, the pumping thread terminate as soon as the java
> task finish.  But then I broke the unit test
> JavaTest#testRedirect1. The test is sending a string as input
> expecting to see it in the output. Before my patch the pumping thread
> was reading the input string but was also closing the stream.

Which side is closing the stream?  I'd think the writing side should do
once it has written the specified string.

> Relying on is.available() cannot tell us if it is actually closed.

With the changes above Thread.interrupted() should eventually return
true when finish is true as well.

> Then I looked into interrupting the read, it doesn't seem to be possible [3].

Right, that's why we have the available() clutch.

> But now I am wondering if it is a false assumption that an input
> stream can close. In "real life" scripting, how would an input stream
> be closed ?

When input is redirected (inputstring attribute or reading from a

We likely should only set useAvailable to true on the input thread if
input is not redirected to avoid unneeded sleeping when we know the
input stream will be closed.

This also means for your failing test case useAvailable would be false
and the test would pass.


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

View raw message