RFR: 8370655: Check EINTR handling InetAddress implementation and NET_ThrowNew

[Michael McMahon]

On Wed, 10 Dec 2025 16:26:39 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Oops. Didn't notice I had left the other calls out. Will add them now.
>> 
>> As for sendto() it's a lot less likely to block and I doubt it can block indefinitely, but I imagine it can block if socket buffer is full. I don't have a strong preference. If EINTR can be returned maybe it should be handled the same way?
>
>> As for sendto() it's a lot less likely to block and I doubt it can block indefinitely, but I imagine it can block if socket buffer is full. I don't have a strong preference. If EINTR can be returned maybe it should be handled the same way?
> 
> Hard to test but I suspect the packet will be dropped rather than blocking. So my guess is that retry here can be simple and doesn't need to use the timeout.

getaddrinfo() and getnameinfo() can potentially return EINTR. The main blocking call in these files is NET_Wait, which is already restarting in the case of EINTR (along with all other errno values). The question is should we be returning an error if errno is _not_ EINTR?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28750#discussion_r2607413746