Mailing-List: contact dev-help@ant.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Ant Developers List" <dev@ant.apache.org>
Received-SPF: softfail (athena.apache.org: transitioning domain of
 nicolas.lalevee@hibnet.org does not designate 216.86.168.183 as permitted
 sender)
Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0 (Apple Message framework v1081)
Subject: Re: bug #49119, threading and IO
From: =?iso-8859-1?Q?Nicolas_Lalev=E9e?= <nicolas.lalevee@hibnet.org>
In-Reply-To: <87sk2dfb6o.fsf@v35516.1blu.de>
Date: Wed, 18 Aug 2010 11:00:42 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <89DC3030-E45E-4A17-A9BE-79B40C643429@hibnet.org>
References: <89CFC9A4-8476-4A48-B80C-7863A4305143@hibnet.org>
 <87sk2dfb6o.fsf@v35516.1blu.de>
To: "Ant Developers List" <dev@ant.apache.org>


Le 17 ao=FBt 2010 =E0 18:36, Stefan Bodewig a =E9crit :

> On 2010-08-15, Nicolas Lalev=E9e wrote:
>=20
>> 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.
>=20
> 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.
>=20
> This is why I marked bug 49587 as a duplicate of 49119.
>=20
>> 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.
>=20
> 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.
>=20
>> 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.
>=20
> Which side is closing the stream?  I'd think the writing side should =
do
> once it has written the specified string.
>=20
>> Relying on is.available() cannot tell us if it is actually closed.
>=20
> With the changes above Thread.interrupted() should eventually return
> true when finish is true as well.
>=20
>> Then I looked into interrupting the read, it doesn't seem to be =
possible [3].
>=20
> Right, that's why we have the available() clutch.
>=20
>> 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 ?
>=20
> When input is redirected (inputstring attribute or reading from a
> resource).
>=20
> 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