Mailing-List: contact dev-help@harmony.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@harmony.apache.org
Received-SPF: pass (athena.apache.org: domain of xu.regis@gmail.com designates
 74.125.92.150 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:user-agent:mime-version:to:subject:references
         :in-reply-to:content-type:content-transfer-encoding;
        b=SFTVG73b7D+sXDVi43nX7nQvFtw7oPzjLxugJldskuGSytVbvJ4HKJKkUXgLvphEMY
         fIrwtE9KCaq+lqprgQZC1EqHwawl8sF4UxF+BHnIegMX0/fOIOgsHV8I2v7dsZXGgcTp
         /phCXahLDSoA7TWBe2qELZG1Ea+psqu8DE2IU=
Message-ID: <4AF392A7.1030504@gmail.com>
Date: Fri, 06 Nov 2009 11:06:15 +0800
From: Regis <xu.regis@gmail.com>
User-Agent: Thunderbird 2.0.0.23 (Windows/20090812)
MIME-Version: 1.0
To: dev@harmony.apache.org
Subject: Re: [classlib] BufferedReader and FileInputStream.available()
References: <96933a4d0911031444j27a2d414l4bbdab74a04ea9e0@mail.gmail.com>
 <4AF0DC18.1000504@gmail.com>
 <200911040821.nA48LtQX030841@d12av01.megacenter.de.ibm.com>
 <4AF2799C.8020807@gmail.com>
 <96933a4d0911051045p61431af5ie2cecb850a62267a@mail.gmail.com>
 <20091105225701.9CBFB478445@athena.apache.org>
In-Reply-To: <20091105225701.9CBFB478445@athena.apache.org>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Mark Hindess wrote:
> In message <96933a4d0911051045p61431af5ie2cecb850a62267a@mail.gmail.com>,
> enh writes:
>> On Wed, Nov 4, 2009 at 23:07, Regis <xu.regis@gmail.com> wrote:
>>> Mark Hindess wrote:
>>>> In message <4AF0DC18.1000504@gmail.com>, Regis writes:
>>>>
>>>> Regis, these are really two different issues so lets treat them as
>>>> such.  I actually think fixing the /proc reading is better done
>>>> in the java code.  I've attached a patch that just catches and
>>>> ignores the IOException from the available call.  I think this is
>>>> reasonable since if the exception was "real" then the read will
>>>> fail if a similar exception.  In fact, since the user is doing
>>>> a read call, having the exception thrown by the read is more in
>>>> keeping with the expectations of the user than having an exception
>>>> thrown by the available call.
>>>
>>> Thanks Mark, I ran luni tests with your patch, no regression found,
>>> I'll leave patch to you to apply :)
>>>
>>> invoking in.available before read is a little overhead, in the
>>> worst case, one read need four system calls, three seek and one
>>> read. Actually the condition
>>>
>>> if ((in.available() = 0) && (out.position() > offset))
>>>
>>> it's only for tty file, for normal file it's not necessary. It's
>>> better if we can remove the check for normal file, but I have no
>>> idea how to do this.
>> isatty(3). for the price of one JNI call at construction and a boolean
>> field to record the result, you could avoid any later calls.
> 
> This might be a good idea, but I'm getting confused...
> 
> At the moment there seems to be a special case in FileInputStream.available()
> like this:
> 
>   // stdin requires special handling
>   if (fd == FileDescriptor.in) {
>     return (int) fileSystem.ttyAvailable();
>   }
>   ... perform seek based available check ...
> 
> but I find this confusing because the comment and check implies that
> stdin is special but the fileSystem method name implies that it is being
> a tty that is the distinction.  This is confusing because *any* file
> descriptor can be a tty - e.g. new FileReader("/dev/tty") - and stdin
> doesn't have to be a tty - "java </dev/zero".

Good question, I suppose here should be like this:
if (istty(fd)) {
   return (int) fileSystem.ttyAvailable(fd);
}

> 
> Regis, can you explain a little more about why the check is needed
> in the available call?  And why the available check is needed in the
> FileInputStream read method?

After I removed the check, everything is fine, except following test is failed:

   public static void main(String args[])
   {
     BufferedReader reader = new BufferedReader(new InputStreamReader(System.in));
     String line = null;
     try {
       line = reader.readLine();
     } catch (IOException e) {
       e.printStackTrace();
     }
     System.out.println(line);
   }

> 
> In each case, is it really stdin that is special or any file descriptor
> representing a tty?
> 
> I'd like to understand this as there are a whole bunch of ttyRead with
> a similar check that only affects stdin not any tty descriptor.
> 
>> in the meantime, i wondered also whether it's worth swapping the two
>> conjuncts in the if, since the latter is essentially free while the
>> former is expensive. (i've no idea how often the cheap conjunct is
>> false, though.)
> 
> I thought about this but held of doing it for the same reason.  However,
> I guess it is almost certainly a win.
> 
> Regards,
>  Mark.
> 
> 
> 


-- 
Best Regards,
Regis.