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. And also the call to |
|
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