On 11/10/2018 09:03, vyom tewari wrote:
Hi Chris,
Thanks for review, please find the updated
webrev(http://cr.openjdk.java.net/~vtewari/8189366/webrev0.1/index.html)
where i included the test.
Can you explain the behavior change for the closed socket case? Will
this change mean that available
On 12/10/18 08:29, Alan Bateman wrote:
On 11/10/2018 09:03, vyom tewari wrote:
Hi Chris,
Thanks for review, please find the updated
webrev(http://cr.openjdk.java.net/~vtewari/8189366/webrev0.1/index.html)
where i included the test.
Can you explain the behavior change for the closed socket c
On 12/10/18 03:46, Chris Yin wrote:
...
Thanks for your suggestion, currently, I just added a comment to explain
the 220 response message and sent updated webrev in earlier thread, I
may prefer to process in that way for now if no objection since separate
specific test added for 8151586 is
Hi,
Maybe a more conservative implementation could have been:
int available = impl.available();
return eof ? 0 : available;
I almost suggested that yesterday, but I saw that
read() already had a logic similar to what Vyom was
proposing for available:
146 // EOF already encounter
Daniel,
On 12/10/18 11:26, Daniel Fuchs wrote:
Hi,
Maybe a more conservative implementation could have been:
int available = impl.available();
return eof ? 0 : available;
That buys us little more than we had prior to this change,
since impl.available will still call into native befor
On Friday 12 October 2018 04:31 PM, Chris Hegarty wrote:
Daniel,
On 12/10/18 11:26, Daniel Fuchs wrote:
Hi,
Maybe a more conservative implementation could have been:
int available = impl.available();
return eof ? 0 : available;
That buys us little more than we had prior to this c
On 12/10/2018 12:01, Chris Hegarty wrote:
That buys us little more than we had prior to this change,
since impl.available will still call into native before
checking the EOF status.
If we want to keep this, then we need:
public int available() throws IOException {
if (impl.isClose
On Fri, Oct 12, 2018 at 6:01 AM Chris Hegarty wrote:
> That is correct. While not intuitive, I don't propose
> that we change this. ( if this were a new implementation
> then I think it should throw IOE for this scenario, but
> we are where we are ).
I am glad then that it is not a new implementa
On 12/10/2018 14:43, David Lloyd wrote:
On Fri, Oct 12, 2018 at 6:01 AM Chris Hegarty wrote:
That is correct. While not intuitive, I don't propose
that we change this. ( if this were a new implementation
then I think it should throw IOE for this scenario, but
we are where we are ).
I am glad t
