-
Notifications
You must be signed in to change notification settings - Fork 17.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
proposal: net: add ErrRetryableAcceptError #66252
Comments
The concept of "retryable" seems as nebulous as the concept of "temporary". Some errors in some contexts are retryable, while the same errors in different contexts are not. What if we instead define a couple of new errors that may be used with |
Similar proposal #60281, but only for |
I think there's some value to capturing the set of errors that
I think the old definition of |
It seems to me that |
Proposal Details
Proposal: Add the following to the
net
package:Implementation will be to add an
Is
method tonet.OpError
which performs the appropriate check.Background/rationale:
Some of the errors returned by
net.Listener.Accept
are potentially transient: While they indicate that theAccept
call has failed, a future call may succeed.Examples include:
EMFILE
: the process is out of file descriptorsENFILE
: the system is out of file descriptorsECONNRESET
andECONNABORTED
: see net/http: possible issues with temporary errors from Accept #6163A server which calls
Accept
may want to ignore all these errors and callAccept
again, probably after some backoff period. One of the uses for the deprecatednet.Error.Temporary
method is to check for these conditions, since we report all of the above as "temporary" errors.As an example,
net/http.Server
usesnet.Error.Temporary
to retry potentially-transientAccept
errors.With the deprecation of
net.Error.Temporary
there is no non-deprecated way to test for these conditions.Temporary
was deprecated, not because it isn't useful to test for retryableAccept
errors but because theTemporary
condition was ill-defined for many other errors, conflated transient errors with timeouts, and was just generally misunderstood. (See #45729.) I propose addingErrRetryableAcceptError
to provide a focused and reasonable well-defined replacement for the specific use case ofAccept
loops.As an alternative, it might be nice if
Accept
just worked and didn't require the user to check for transient errors. However, that would require changing long-established behavior, and defining correct handling ofEMFILE
(for one example) seems challenging. This proposal is less ambitious in scope.Further references:
The text was updated successfully, but these errors were encountered: