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

[release/7.0][wasm-mt] Fix pack/build issues in threaded builds #75171

Merged
merged 10 commits into from
Sep 8, 2022

Conversation

lambdageek
Copy link
Member

Manual backport of #75162

Addresses the following issues in #74654:

  • dotnet.worker.js missing from the runtime pack
  • WorkloadManifest.targets.in uses WasmEnableThreading instead of WasmEnableThreads
  • The CoreLibs in the multithread and perftrace build variants don't define the correct feature flags.
  • dotnet new wasmbrowser creates browser.csproj, not <dirname>.csproj

@dotnet-issue-labeler
Copy link

I couldn't figure out the best area label to add to this PR. If you have write-permissions please help me learn by adding exactly one area label.

@lambdageek lambdageek added the arch-wasm WebAssembly architecture label Sep 6, 2022
@ghost
Copy link

ghost commented Sep 6, 2022

Tagging subscribers to 'arch-wasm': @lewing
See info in area-owners.md if you want to be subscribed.

Issue Details

Manual backport of #75162

Addresses the following issues in #74654:

  • dotnet.worker.js missing from the runtime pack
  • WorkloadManifest.targets.in uses WasmEnableThreading instead of WasmEnableThreads
  • The CoreLibs in the multithread and perftrace build variants don't define the correct feature flags.
  • dotnet new wasmbrowser creates browser.csproj, not <dirname>.csproj
Author: lambdageek
Assignees: lambdageek
Labels:

arch-wasm

Milestone: -

@lambdageek lambdageek added Servicing-consider Issue for next servicing release review area-Build-mono and removed Servicing-consider Issue for next servicing release review labels Sep 6, 2022
@lambdageek
Copy link
Member Author

Ah, the backport had to be done manually because the workload manifest is now src/mono/nuget/Microsoft.NET.Workload.Mono.Toolchain.net7.Manifest/WorkloadManifest.targets.in

The workload resolver already did its job by the time this property is
updated, so we need to use patterns that correspond to actual nupkg
names (unversioned), not runtime pack alias names from the
manifest (versioned with 'net7')
For local testing if the built runtime is a multithreaded one, make
and we need to make the normal variant nuget, unset
MonoWasmBuildVariant property
@lambdageek
Copy link
Member Author

WasmBuildTests is now failing because this hack is no longer necessary and it's messing up the IncludedWorkloadManifests.txt file. The newest SDK that dotnet-install.sh pulls down ( 7.0.100-rc.2.22457.6) has the .net6 and .net7 toolchains already

// HACK BEGIN - because sdk doesn't yet have the net6/net7 manifest names in the known workloads
// list
string? txtPath = Directory.EnumerateFiles(Path.Combine(SdkWithNoWorkloadInstalledPath, "sdk"), "IncludedWorkloadManifests.txt",
new EnumerationOptions { RecurseSubdirectories = true, MaxRecursionDepth = 2})
.FirstOrDefault();
if (txtPath is null)
throw new LogAsErrorException($"Could not find IncludedWorkloadManifests.txt in {SdkWithNoWorkloadInstalledPath}");
string stampPath = Path.Combine(Path.GetDirectoryName(txtPath)!, ".stamp");
if (!File.Exists(stampPath))
{
Log.LogMessage(MessageImportance.High, $"txtPath: {txtPath}");
string newTxt = File.ReadAllText(txtPath)
.Replace("microsoft.net.workload.mono.toolchain",
$"microsoft.net.workload.mono.toolchain.net6{Environment.NewLine}microsoft.net.workload.mono.toolchain.net7")
.Replace("microsoft.net.workload.emscripten",
$"microsoft.net.workload.emscripten.net6{Environment.NewLine}microsoft.net.workload.emscripten.net7");
File.WriteAllText(txtPath, newTxt);
File.WriteAllText(stampPath, "");
}
string p = Path.Combine(SdkWithNoWorkloadInstalledPath, "sdk-manifests", "7.0.100", "microsoft.net.workload.mono.toolchain");
Log.LogMessage(MessageImportance.High, $"Deleting {p}");
if (Directory.Exists(p))
Directory.Delete(p, recursive: true);
p = Path.Combine(SdkWithNoWorkloadInstalledPath, "sdk-manifests", "7.0.100", "microsoft.net.workload.emscripten");
Log.LogMessage(MessageImportance.High, $"Deleting {p}");
if (Directory.Exists(p))
Directory.Delete(p, recursive: true);
// HACK END

Starting with 7.0.100-rc.2.22457.6 we already have the versioned
net6/net7 toolchains, so the hack isn't needed anymore (and in fact,
breaks workload installation during testing)
@lambdageek
Copy link
Member Author

WasmBuildTests is now failing because this hack is no longer necessary

Pushed a fix to this PR to remove the hack. Separately opened #75198 to remove the hack on release/7.0-rc1

@lambdageek
Copy link
Member Author

This should be ready to go now.

Could I get a review and approval @radical @lewing @marek-safar

Comment on lines +106 to +107
<RuntimePackNamePatterns Condition="'$(RuntimeIdentifier)' == 'browser-wasm' and '$(WasmEnableThreads)' == 'true'">Microsoft.NETCore.App.Runtime.Mono.multithread.**RID**</RuntimePackNamePatterns>
<RuntimePackNamePatterns Condition="'$(RuntimeIdentifier)' == 'browser-wasm' and '$(WasmEnablePerfTracing)' == 'true'">Microsoft.NETCore.App.Runtime.Mono.perftrace.**RID**</RuntimePackNamePatterns>
Copy link
Member

Choose a reason for hiding this comment

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

Just wondering - should we have WasmEnableThreading to match WasmEnablePerfTrac*ing*?

Copy link
Member Author

Choose a reason for hiding this comment

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

Maybe. 😁

I'm not really happy with either of these names. "perf tracing" is not really a great name either.

I think the customer-facing names should be reworked over in net8.

Copy link
Member

Choose a reason for hiding this comment

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

@lewing @steveisok thoughts?

Copy link
Member

Choose a reason for hiding this comment

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

In net8 we could try an item with list of features to enable, like the runtime components stuff.

Copy link
Member

Choose a reason for hiding this comment

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

I don't have any good suggestions :-).

@radical
Copy link
Member

radical commented Sep 7, 2022

WBT has failures on windows due to networking issues, so trying once more.

@carlossanlop
Copy link
Member

@marek-safar we need an approval please.
@lambdageek please ping me for merging after the discussions are resolved and the CI failures are determined to be unrelated.

@radical
Copy link
Member

radical commented Sep 7, 2022

@carlossanlop this is ready to go

@carlossanlop
Copy link
Member

@radical @lambdageek @steveisok is this tell-mode or ask-mode? I see some product code changes, even though most seem to be infra. The area label isn't making it clear.

@lambdageek
Copy link
Member Author

lambdageek commented Sep 7, 2022

Update pushed

I need to push one more commit here. System.Runtime.InteropServices.JavaScript also needs to be built with a MonoWasmBuildVariant check in the .csproj. Otherwise we don't get the browser synchronization context installed.

@lambdageek
Copy link
Member Author

@carlossanlop tell mode. this is to support wasm multithreading, which is a preview feature in net7

@lambdageek
Copy link
Member Author

@carlossanlop :shipit:

@lewing lewing merged commit f85d370 into dotnet:release/7.0 Sep 8, 2022
lambdageek added a commit to lambdageek/runtime that referenced this pull request Sep 8, 2022
Foward port changes from `release/7.0` dotnet#75171
that were not included in `main` dotnet#75162

- when building the InteropServices.JavaScript library, enable
threading if MonoWasmBuildVariant is set appropriately.  One
consequence is that the runtime will (correctly) install the browser
synchronization context on the main thread.

- for workload build testing, unset MonoWasmBuildVariant when creating
the non-threaded runtime
lambdageek added a commit that referenced this pull request Sep 12, 2022
Foward port changes from `release/7.0` #75171
that were not included in `main` #75162

- when building the InteropServices.JavaScript library, enable
threading if MonoWasmBuildVariant is set appropriately.  One
consequence is that the runtime will (correctly) install the browser
synchronization context on the main thread.

- for workload build testing, unset MonoWasmBuildVariant when creating
the non-threaded runtime
@ghost ghost locked as resolved and limited conversation to collaborators Oct 8, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
arch-wasm WebAssembly architecture area-Build-mono
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants