ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicolas Lalevée <>
Subject Re: bug #49119, threading and IO
Date Wed, 18 Aug 2010 09:00:42 GMT

Le 17 août 2010 à 18:36, Stefan Bodewig a écrit :

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

seems the best option, true.

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

Actually if we keep the read blocking behavior when an input file or string is provided, the
end-of-stream will be still transmitted. So the unit test won't hang up.

This solution fits nicely with each use case. I'll work on the fix.


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

View raw message