Hi Vyom,

the build on AIX was successful.

Best regards
Christoph

> -----Original Message-----
> From: Langer, Christoph
> Sent: Montag, 22. August 2016 14:40
> To: 'Vyom Tewari' <vyom.tew...@oracle.com>; net-dev <net-
> d...@openjdk.java.net>
> Subject: RE: RFR 8075484:SocketInputStream.socketRead0 can hang even with
> soTimeout set
> 
> Hi Vyom,
> 
> to me the change looks good, apart from a few minor cosmetical remarks:
> 
> in SocketInputStream.c (new):
> line 71: if (_timeout > 0) {
> -> I think the if is indented by one space too much
> line 109: LABEL:  if (_timeout) {
> -> as the length of "LABEL: " is more than 4 chars and hence the if is 
> indented
> too far, I suggest to put the label in a row before. And also, maybe give it a
> more descriptive name
> line 135:             if(_timeout > 0){
> -> you should put a space after the if and in between ){
> 
> I'll also build it on AIX but don't expect issues. I'l llet you know.
> 
> Please also not, that I'm not an official reviewer.
> 
> Best regards
> Christoph
> 
> > -----Original Message-----
> > From: net-dev [mailto:net-dev-boun...@openjdk.java.net] On Behalf Of
> Vyom
> > Tewari
> > Sent: Montag, 22. August 2016 13:42
> > To: net-dev <net-dev@openjdk.java.net>
> > Subject: RFR 8075484:SocketInputStream.socketRead0 can hang even with
> > soTimeout set
> >
> > Hi All,
> >
> > Please review the code changes for below issue.
> >
> > Bug         : https://bugs.openjdk.java.net/browse/JDK-8075484
> >
> > webrev    :
> > http://cr.openjdk.java.net/~vtewari/8075484/webrev0.0/index.html
> > <http://cr.openjdk.java.net/%7Evtewari/8075484/webrev0.0/index.html>
> >
> > This issue is SocketInputStream.socketread0() hangs even with
> > "soTimeout" set.the implementation of
> > Java_java_net_SocketInputStream_socketRead0 assumes that read() won't
> > block after poll() reports that a read is possible.
> >
> > This assumption does not hold, as noted on the man page for select
> > (referenced by the man page for poll): Under Linux, select() may report
> > a socket file descriptor as "ready for reading", while nevertheless a
> > subsequent read blocks. This could for example happen when data has
> > arrived but upon examination has wrong checksum and is discarded.
> >
> > Thanks,
> >
> > Vyom
> >

Reply via email to