-
Notifications
You must be signed in to change notification settings - Fork 4.7k
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
[WASI] System.Net.NameResolution #107351
[WASI] System.Net.NameResolution #107351
Conversation
Tagging subscribers to this area: @dotnet/ncl |
dc15610
to
90a7b23
Compare
This comment was marked as resolved.
This comment was marked as resolved.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good. There's a small nit, sometimes you do #endif // !TARGET_WASI
and sometimes #endif // TARGET_WASI
for if !defined(TARGET_WASI)
in C code, it's not uniform.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For in-box assemblies use OperatingSystem.IsWasi() instead of #ifdefs whenever possible, the branch will be optimized out in nearly every case. In the pal try to use feature specific #ifdefs like HAVE_EPOLL etc.
Done |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM. Seems like this is mostly plumbing to get it build, right?
...ibraries/System.Net.NameResolution/tests/PalTests/System.Net.NameResolution.Pal.Tests.csproj
Outdated
Show resolved
Hide resolved
src/libraries/System.Net.NameResolution/tests/FunctionalTests/TelemetryTest.cs
Outdated
Show resolved
Hide resolved
...m.Net.NameResolution/tests/FunctionalTests/System.Net.NameResolution.Functional.Tests.csproj
Outdated
Show resolved
Hide resolved
src/libraries/System.Net.NameResolution/tests/FunctionalTests/MetricsTest.cs
Outdated
Show resolved
Hide resolved
src/libraries/System.Net.NameResolution/tests/FunctionalTests/LoggingTest.cs
Outdated
Show resolved
Hide resolved
src/libraries/System.Net.NameResolution/tests/FunctionalTests/GetHostEntryTest.cs
Outdated
Show resolved
Hide resolved
src/libraries/System.Net.NameResolution/src/System/Net/NameResolutionTelemetry.cs
Outdated
Show resolved
Hide resolved
src/libraries/System.Net.NameResolution/src/System/Net/NameResolutionPal.Unix.cs
Outdated
Show resolved
Hide resolved
Co-authored-by: Alexander Köplinger <alex.koeplinger@outlook.com>
…LoggingTest.cs Co-authored-by: Alexander Köplinger <alex.koeplinger@outlook.com>
…TelemetryTest.cs Co-authored-by: Alexander Köplinger <alex.koeplinger@outlook.com>
…MetricsTest.cs Co-authored-by: Alexander Köplinger <alex.koeplinger@outlook.com>
…olutionPal.Unix.cs Co-authored-by: Alexander Köplinger <alex.koeplinger@outlook.com>
*pathOffset = offsetof(struct sockaddr_un, sun_path); | ||
*pathSize = sizeof(domainSocket.sun_path); | ||
#else // HAVE_SOCKADDR_UN_SUN_PATH | ||
*pathOffset = 0; | ||
*pathSize = 0; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
should this return -1 like in the previous WASI implementation?
looking at the managed code we have Debug.Assert that checks pathSize >= 92 in UnixDomainSocketEndPoint.Unix.cs, we should probably return -1 here again and add code to not call GetDomainSocketSizes on Wasi there.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That's in static constructor and would throw.
Let's revisit that on the socket PR #106977 I added todo there
if (OperatingSystem.IsWasi()) | ||
{ | ||
return "localhost"; | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: it feels slightly wrong doing this special case in the Interop.GetHostName.cs managed binding layer, but calling into native code just for getting a constant string feels wrong too.
Btw. after looking at it some more I think we have an issue on Browser: we do use emscripten's gethostname() which returns the string emscripten
and we just paper over it here:
runtime/src/libraries/System.Private.CoreLib/src/System/Environment.Browser.cs
Lines 13 to 15 in 4cdbfdc
// In the mono runtime, this maps to gethostname, which returns 'emscripten'. | |
// Returning the value here allows us to exclude more of the runtime. | |
public static string MachineName => "localhost"; |
But Interop.Sys.GetHostName() is used in more places and those would get the "wrong" hostname on Browser. I think I'd be in favor of unifying this and adding the special case for Browser here too.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let's do separate PR for that
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Co-authored-by: Alexander Köplinger <alex.koeplinger@outlook.com>
Co-authored-by: Alexander Köplinger <alex.koeplinger@outlook.com>
#ifdef
inpal_networking.c
pal_networking_wasi.c
getnameinfo
->PlatformNotSupportedException
gethostname
, we returnlocalhost
NameResolutionTelemetry
Dns.Begin
*,Dns.End
APIs ->PlatformNotSupportedException
[UnsupportedOSPlatform]
will come bit laterEAI_SYSTEM
codeSystem.Net.NameResolution.Functional.Tests
to WASI smoke test on CICreated ActiveIssue #107339