Skip to content
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

Merged
merged 19 commits into from
Sep 12, 2024
Merged

[WASI] System.Net.NameResolution #107351

merged 19 commits into from
Sep 12, 2024

Conversation

pavelsavara
Copy link
Member

@pavelsavara pavelsavara commented Sep 4, 2024

  • based on unix
  • use #ifdef in pal_networking.c
  • drop pal_networking_wasi.c
  • WASI doesn't have getnameinfo -> PlatformNotSupportedException
  • WASI doesn't have gethostname, we return localhost
  • WASI is single threaded
    • dummy implementation of NameResolutionTelemetry
    • no suport for Dns.Begin*, Dns.End APIs -> PlatformNotSupportedException
  • [UnsupportedOSPlatform] will come bit later
  • conversion for EAI_SYSTEM code
  • addded System.Net.NameResolution.Functional.Tests to WASI smoke test on CI

Created ActiveIssue #107339

@pavelsavara pavelsavara added arch-wasm WebAssembly architecture area-System.Net os-wasi Related to WASI variant of arch-wasm labels Sep 4, 2024
@pavelsavara pavelsavara added this to the 10.0.0 milestone Sep 4, 2024
@pavelsavara pavelsavara self-assigned this Sep 4, 2024
Copy link
Contributor

Tagging subscribers to this area: @dotnet/ncl
See info in area-owners.md if you want to be subscribed.

@pavelsavara

This comment was marked as resolved.

Copy link
Member

@ilonatommy ilonatommy left a 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.

Copy link
Member

@lewing lewing left a 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.

@pavelsavara
Copy link
Member Author

image

@pavelsavara
Copy link
Member Author

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

Copy link
Member

@wfurt wfurt left a 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?

*pathOffset = offsetof(struct sockaddr_un, sun_path);
*pathSize = sizeof(domainSocket.sun_path);
#else // HAVE_SOCKADDR_UN_SUN_PATH
*pathOffset = 0;
*pathSize = 0;
Copy link
Member

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.

Copy link
Member Author

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";
}
Copy link
Member

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:

// 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.

Copy link
Member Author

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

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@pavelsavara pavelsavara merged commit a833cfb into dotnet:main Sep 12, 2024
158 of 161 checks passed
@pavelsavara pavelsavara deleted the wasi_dns branch September 12, 2024 14:41
jtschuster pushed a commit to jtschuster/runtime that referenced this pull request Sep 17, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
arch-wasm WebAssembly architecture area-System.Net os-wasi Related to WASI variant of arch-wasm
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants