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 intputstream.read 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 System.in - 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. This also means for your failing test case useAvailable would be false and the test would pass. Stefan --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org