Re: JEP 321 surface-level comments

2018-05-25 Thread Chris Hegarty
Chris, On HttpRequest. While everything is functioning as expected, it may be possible to clean up the HttpRequest instances built through the builder, making it easier to reason about the code. It seems like a straight forward change to have WebSocket use an internal API to create its

Re: JEP 321 surface-level comments

2018-05-25 Thread Chris Hegarty
Chris, On HttpHeaders, I'll reply to your comments on HttpResponse separately. Given the long thread, I'll try to summarize here rather and answering specific comments inline, but I have read and attempted to address each of them. As you have correctly observed, the current implementation

Re: RFR 8203369 : Check for both EAGAIN and EWOULDBLOCK error codes

2018-05-25 Thread Chris Hegarty
Alan, On 25/05/18 12:27, Alan Bateman wrote: On 24/05/2018 21:57, Ivan Gerasimov wrote: .. WEBREV: http://cr.openjdk.java.net/~igerasim/8203369/00/webrev/ The changes in 01/webrev look okay to me but I'm curious if there are any ports in OpenJDK where the values are different. HPUX 11.31 (

Re: RFR 8203369 : Check for both EAGAIN and EWOULDBLOCK error codes

2018-05-25 Thread Alan Bateman
On 24/05/2018 21:57, Ivan Gerasimov wrote: Hello! On Unix systems several system calls (including pread, read, readv, recvfrom, recvmsg, send, sendfile, sendmsg, sendto) may set errno to either EAGAIN or EWOULDBLOCK on the same condition. On Linux these two constants are the same, but they

Re: RFR 8203369 : Check for both EAGAIN and EWOULDBLOCK error codes

2018-05-25 Thread David Holmes
On 25/05/2018 4:14 PM, Ivan Gerasimov wrote: Hi David! If gcc, then we already have the same test for both constants in code with no issues. For example, java.base/unix/native/libnet/SocketInputStream.c, in NET_ReadWithTimeout(): result = NET_NonBlockingRead(fd, bufP, len);

Re: RFR 8203369 : Check for both EAGAIN and EWOULDBLOCK error codes

2018-05-25 Thread Ivan Gerasimov
On 5/24/18 10:25 PM, Weijun Wang wrote: https://stackoverflow.com/questions/27509061/macro-to-avoid-duplicate-case-value Someone has already used them in a switch expression... Interesting! I like the very first solution: #if EAGAIN != EWOULDBLOCK case EAGAIN: #endif case

Re: RFR 8203369 : Check for both EAGAIN and EWOULDBLOCK error codes

2018-05-25 Thread Ivan Gerasimov
Hi David! If gcc, then we already have the same test for both constants in code with no issues. For example, java.base/unix/native/libnet/SocketInputStream.c, in NET_ReadWithTimeout(): result = NET_NonBlockingRead(fd, bufP, len); if (result == -1 && ((errno == EAGAIN) ||

Re: RFR 8203369 : Check for both EAGAIN and EWOULDBLOCK error codes

2018-05-25 Thread vyom tewari
On Friday 25 May 2018 11:19 AM, Ivan Gerasimov wrote: Hi Wiijun! On 5/24/18 10:13 PM, Weijun Wang wrote: On May 25, 2018, at 11:58 AM, Ivan Gerasimov wrote: I also wonder whether a smart compiler might not flag code where the errors do infact have the same