On Wed, 10 Dec 2025 16:26:39 GMT, Alan Bateman <[email protected]> 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
