Socket InputStream.available may return a positive value after shutdown

Jing LV lvjing at linux.vnet.ibm.com
Thu Jul 21 01:42:37 PDT 2011


Hi,

     Thank you Chris! Would you please send the link when you have some 
progress?

于 2011-7-18 18:00, Chris Hegarty 写道:
> On 07/18/11 09:09 AM, Jing LV wrote:
>> Hi Chris, Alan,
>>
>> Thanks for reply. I am looking for a conclusion and solution for this
>> issue. If I understand correctly, it'd fix the spec rather than fix the
>> code?
>
> The current plan of record is to clarify the spec to indicate that 
> available will return 0 after shutdownInput is invoked. Then change 
> the implementation to do just this.
>
> I'll send out a webrev soon.
>
> -Chris.
>
>>
>> 于 2011-7-14 17:00, Chris Hegarty 写道:
>>> On 07/14/11 09:36 AM, Alan Bateman wrote:
>>>> Chris Hegarty wrote:
>>>>> :
>>>>>
>>>>> I can't see that anyone could be depending on the fact the 
>>>>> available()
>>>>> would return > 0 after shutdownInput(), given that subsequent reads
>>>>> will always return -1. I just can't see why anyone would require 
>>>>> this,
>>>>> but maybe I'm missing something.
>>>> You're probably right, and it's just the concern that there may be 
>>>> code
>>>> that won't now read and see the end-of-stream. The other concern is 
>>>> that
>>>
>>> Yes, interesting point. I think this may be less of a concern though.
>>> Can anyone even depend on this today, i.e. use available to determine
>>> when to read and expect to reach eof? I don't think so because they
>>> may just happen to read the exact amount of data being sent and
>>> available will always return 0.
>>>
>>> Also, it does seems unlikely that this change would surprise too may
>>> people, they are calling shutdownInput explicitly on the socket.
>>>
>>> Let me put together a webrev and see the extent of the changes.
>>>
>>> -Chris.
>>>
>>>> we don't know how custom SocketImpls might behave. Overall the risk 
>>>> does
>>>> seem low.
>>>>
>>>> -Alan.
>>
>>


-- 
Best Regards,
Jimmy, Jing LV





More information about the net-dev mailing list