Change https://golang.org/cl/203117 mentions this issue: net: treat ENFILE from accept as a temporary error

On Windows, there's WSAEMFILE but according to the page below WSAENOBUFS is more likely, so maybe that should be added on the Windows side?

https://emptyhammock.com/blog/wsaemfile.html

/cc @mikioh per owners.

If we're going to change this we should change it in the syscall package, in Errno.Temporary, not in the net package.

Looks like the check for EMFILE was added in https://golang.org/cl/4550112, but we somehow failed to consider checking for ENFILE at that time. CC @bradfitz who wrote 4550112 in case he remembers anything.

Also WSAEMFILE & WSAENOBUFS for syscall_windows.go

cc @alexbrainman @mattn @zx2c4

I've updated the CL to change Errno.Temporary as suggested by @ianlancetaylor. Can someone else tackle the Windows part, or split it into a separate issue? I don't have access to a Windows machine for testing.

This is fixed on Unix systems, but reopening for Windows.

Change https://golang.org/cl/208537 mentions this issue: syscall: treat ENFILE as a temporary error for Windows

@alexbrainman @ianlancetaylor the CL for Windows has now eliminated syscall.ENFILE instead of adding WSAEMFILE & WSAENOBUFS to the .Temporary() set. I think we want the latter, and not the former.

Tuning the list of Errno constants for Windows is #32309; a CL for it should consider all the "fake" Errno constants defined in pkg syscall, and decide whether to drop them or set them to a common value.

cc @iwdgo

We shouldn't touch any of the fake Errno constants defined for Windows in the syscall package. The gain from that would not be worth the break in backward compatibility.

@ianlancetaylor can you endorse adding the WSA* errors I listed to .Temporary()? I believe that was the point of reopening this, but Constantin doesn't believe me :-)

https://emptyhammock.com/blog/wsaemfile.html

@alexbrainman this is the rationale for the CL you asked about.

Yes, I think that is the appropriate change here.

Ian, there is a misunderstanding in the CL thread. Can you reply there, and drop your -2?

https://golang.org/cl/208537

@alexbrainman can you explain why WSAEMFILE & WSAENOBUFS are not temporary errors?

This reference shows the latter occurs when server is loaded:
https://emptyhammock.com/blog/wsaemfile.html

@alexbrainman sorry, the link I mentioned is posted in this thread, including immediately above. Unfortunately it doesn't give the code he used, but that should be simple to recreate if nec.

@djdv this is the only open issue for temporary WSA errors. The original CL author has ceased working on it. If you'd like to take over that work and include the other WSA error you found, that would be great!

See https://golang.org/doc/contribute.html

@networkimprov
Thanks for that.
I'll put this on my TODO list, but I have some other things to take care of first. If someone wants to beat me to it that'd be fine. :^)
Otherwise I'll look into this soon-ish. (I'll read this thread and linked things in full later)

Specifically, I/someone need(s) to go through the WSA error list and figure out which should be considered "temporary" / what net considers to be "temporary".
Initial assumption being that; as long as the connection can have a successful read in subsequent calls, that it is to be considered temporary. (leaving errors that render the socket unusable as they are now)

I think you'd want empirical evidence that an error isn't a cause to drop the connection (and some probably don't occur in practice), so I don't think you'd need to review the WSA list. Let's just add the two discussed above and the one you found.

I think there are only minor scope problems with the posted CL.