ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicolas Lalevée <>
Subject bug #49119, threading and IO
Date Sun, 15 Aug 2010 12:22:44 GMT
I try to fix the bug #49119 [1] but I have some threading and IO issues.

The bug is about a forked <java> stealing characters from the input stream even if is
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.

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. 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. Relying on is.available() cannot tell us if it is
actually closed. The other end of the stream JavaTest#PipeEntryPoint is expecting a closed
input at some point so it doesn't know where to stop redirecting everything from input to
the output. Then with my patch it is hanging indefinitely.

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

Another fix I thought is about closing the output if the input is empty: if is.available()
== 0 and closeWhenExhausted == true, then do stop the pumping and close. But it seems quite
dangerous if some input stream is quite slow.

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 ? It should be opened as long as the
user is typing on his keyboard, isn't it ? So maybe just the unit test is doing false assumption



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

View raw message