[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ant-dev
Subject:    Re: bug #49119, threading and IO
From:       Nicolas_Lalevée <nicolas.lalevee () hibnet ! org>
Date:       2010-08-18 9:00:42
Message-ID: 89DC3030-E45E-4A17-A9BE-79B40C643429 () hibnet ! org
[Download RAW message or body]


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

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.
thanks.

Nicolas


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


[prev in list] [next in list] [prev in thread] [next in thread]