Hi Ivan,
On 25/05/2018 1:58 PM, Ivan Gerasimov wrote:
Hi David!
Thank you for reviewing the fix!
I looked but did not review - it was just an observation :)
On 5/24/18 7:44 PM, David Holmes wrote:
Hi Ivan,
Just a thought, but just because the actual native function may return
either code, that doesn't mean our native wrapper can't treat them the
same and present them to the Java code as one error?
Currently in some places we check for only one of the values (on the
supported platforms we could have being checking for the other with
exactly same effect). In other places we already check for both values,
so it is proposed to do it consistently with accordance to the
documentation.
It seems pointless to double up these condition checks everywhere just
in case there is some platform (do we know of one?) where this may be
necessary.
That's exactly what man pages suggest: "...a portable application should
check for both..."
Yes but that's the native code that calls the library methods. That
doesn't necessarily mean we have to propagate the ambiguity through our
own native wrappers and/or Java code.
And yes, there exist such platforms.
I also wonder whether a smart compiler might not flag code where the
errors do infact have the same value:
if (errno == 11 || errno == 11) ...
At least gcc -O completely removes the second redundant test, so no
observable changes is expected on supported platforms.
I'm more worried about a new compiler warning - especially if you
happened to use them in a switch! - resulting in future build failures.
Cheers,
David
With kind regards,
Ivan
Cheers,
David
On 25/05/2018 6:57 AM, 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 are not required
to be the same.
For example, here's an extract from the Linux man page of send():
EAGAIN or EWOULDBLOCK
The socket is marked nonblocking and the requested operation would
block. POSIX.1-2001 allows either error to be returned for this
case, and does not require these constants to have the same value, so
a portable application should check for both possibilities.
We should check for both error codes when appropriate.
Would you please help review the fix?
BUGURL: https://bugs.openjdk.java.net/browse/JDK-8203369
WEBREV: http://cr.openjdk.java.net/~igerasim/8203369/00/webrev/
Thanks!
