-
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
Add GCHandle in native default ALC at creation #53308
Conversation
Tagging subscribers to this area: @CoffeeFlux Issue DetailsThis lets embedders have a handle to fetch and pass before the runtime is properly started up and the managed default ALC is not yet created. Once the managed counterpart is initialized, the handle's target is changed, but the handle stays the same. cc: @grendello
|
The failures are caused because of the code in native-library.c, which used to pass a 0 gchandle to the managed callbacks, and now it passes a non-0 one. Adding something like: fixes it. |
2535d6a
to
3936d25
Compare
Failures look related. runtime/src/mono/System.Private.CoreLib/src/System/Runtime/Loader/AssemblyLoadContext.Mono.cs Lines 121 to 147 in 897072a
And also the call to runtime/src/libraries/System.Private.CoreLib/src/System/Runtime/Loader/AssemblyLoadContext.cs Line 607 in 897072a
|
Yeah, I need to go through more carefully and see where we're actually using the GCHandle. There aren't that many uses, so I can just check them all. |
This lets embedders have a handle to fetch and pass before the runtime is properly started up and the managed default ALC is not yet created. Once the managed counterpart is initialized, the handle's target is changed, but the handle stays the same.
3936d25
to
5274cf1
Compare
Context: https://docs.microsoft.com/dotnet/api/system.runtime.loader.assemblyloadcontext?view=net-5.0 .NET Core -- and thus, .NET 5+ -- removed most support for `System.AppDomain` -- technically, there still exists a single `AppDomain`, but creation of new ones is no longer possible -- with [`System.Runtime.Loader.AssemblyLoadContext`][0] acting as the replacement for *some* previous `AppDomain` functionality. TL;DR: `AssemblyLoadContext` allows (potentially) loading and unloading assemblies, but *doesn't* allow creating an in-process "sandbox" like `AppDomain` originally did. ([Code Access Security][1] was deprecated by .NET Framework 4 and [isn't present in .NET 5][2]; `AppDomain` for sandboxing purposes was, in retrospect, rarely a good idea.) Commit 0cd890b introduced partial support for using `AssemblyLoadContext`, but it was necessarily incomplete until after [dotnet/runtime#53308][3] and other fixes landed. Add support for calling the new `AssemblyLoadContext`-oriented MonoVM functions to load an assembly into either the default `AssemblyLoadContext` (early in the startup process) or into the application-created context later on during application run time. MonoVM also adds new preload hooks which work with the `AssemblyLoadContext` instead of the older AppDomains. [0]: https://docs.microsoft.com/dotnet/api/system.runtime.loader.assemblyloadcontext?view=net-5.0 [1]: https://docs.microsoft.com/previous-versions/dotnet/framework/code-access-security/code-access-security [2]: https://docs.microsoft.com/dotnet/core/compatibility/core-libraries/5.0/code-access-security-apis-obsolete#reason-for-change [3]: dotnet/runtime#53308
This lets embedders have a handle to fetch and pass before the runtime is properly started up and the managed default ALC is not yet created. Once the managed counterpart is initialized, the handle's target is changed, but the handle stays the same.
Fixes #48610
cc: @grendello