When AFD is unsupported, return an error that can be traced back to the original I/O error #174
Comments
notgull
added a commit
that referenced
this issue
Jan 8, 2024
Previously, if AFD failed to initialize `polling` would return a custom I/O error with a string error, containing the formatted version of the underlying system error. However, this means that information about the underlying system error is lost to the user. This commit makes it so the returned `io::Error` wraps a user inaccessible type: `AfdError`. This `AfdError`, when stringified, returns a similar error message as what was previously returned. In addition when `.source()` is used it returns the underlying system error. Closes #174 Signed-off-by: John Nunley <dev@notgull.net>
notgull
added a commit
that referenced
this issue
Jan 9, 2024
Previously, if AFD failed to initialize `polling` would return a custom I/O error with a string error, containing the formatted version of the underlying system error. However, this means that information about the underlying system error is lost to the user. This commit makes it so the returned `io::Error` wraps a user inaccessible type: `AfdError`. This `AfdError`, when stringified, returns a similar error message as what was previously returned. In addition when `.source()` is used it returns the underlying system error. Closes #174 Signed-off-by: John Nunley <dev@notgull.net>
Merged
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Before we use the Windows IOCP backend we quickly test to see if the AFD hack is available. If it isn't we return an error that mentions old Windows or WINE, in order to indicate that this is the likely cause.
However, it would be nice if we instead returned an
io:Errorthat wraps a custom error struct. It would still have the nice message but it'ssource()would be the underlying I/O error.The text was updated successfully, but these errors were encountered: