NSAutoreleasePool instance should be added to all threads.#52023
NSAutoreleasePool instance should be added to all threads.#52023AaronRobinsonMSFT merged 42 commits intodotnet:mainfrom
Conversation
item and pass it to corerun.
This expands the current support where support was only added to ThreadPool threads. Now all managed threads or new native threads entering the runtime will get an NSAutoreleasePool allocated. New feature switch was created and the ThreadPool one was removed. - System.Threading.Thread.EnableAutoreleasePool Updated AutoReleaseTest for the new scenarios.
src/libraries/System.Private.CoreLib/src/System/Threading/Thread.OSX.cs
Outdated
Show resolved
Hide resolved
src/libraries/System.Private.CoreLib/src/System/Threading/Thread.OSX.cs
Outdated
Show resolved
Hide resolved
…ool. If feature is not enabled, allocating a NSAutoreleasePool is a no-op.
|
@lambdageek I took a quick look at how to call these P/Invokes in mono. It isn't obvious to me how to try adding support. My best guess is around runtime/src/mono/mono/metadata/threads.c Lines 1160 to 1173 in 01b7e73 If you think this support should be easy to add, I'm willing to take a few hours to try it out. |
What needs to happen? a call to yea I think the right place is right before both callers of runtime/src/mono/mono/metadata/threads.c Lines 1600 to 1601 in 01b7e73 That one would set up an autorelease pool when a foreign thread attaches to the runtime via a pinvoke callback. (eg: managed code calls a pinvoke and passes it a delegate (or an In general the pattern to follow is like this: runtime/src/mono/mono/metadata/threads.c Lines 878 to 898 in 01b7e73 (some things to note: 1. if the method may not be present (removed by the IL Linker, or not defined on every plaform), don't assert; 2. |
linker can keep even though the runtime won't call the function.
Co-authored-by: Jan Kotas <jkotas@microsoft.com>
This comment has been minimized.
This comment has been minimized.
needed or possible in some cases (e.g. GC).
with the thread type needed - GC.
Remove GetUniqueEEId() logic.
Remove check for AbortRequest from TransferStartedThread().
- This can be done because it is only called from HasStarted() so
the user has no chance to make the request and we don't support
custom hosting.
- The only other place this work occurs is during a FuncEval - which
again means the thread is running manage code and after the call to
the HasStarted() call.
src/libraries/System.Private.CoreLib/src/System/Threading/Thread.cs
Outdated
Show resolved
Hide resolved
Move main thread initialization/cleanup closer to when Main is called.
src/mono/System.Private.CoreLib/src/ILLink/ILLink.Descriptors.xml
Outdated
Show resolved
Hide resolved
src/libraries/System.Private.CoreLib/src/System/Threading/Thread.OSX.cs
Outdated
Show resolved
Hide resolved
src/libraries/System.Private.CoreLib/src/System/Threading/Thread.OSX.cs
Outdated
Show resolved
Hide resolved
src/libraries/System.Private.CoreLib/src/System/Threading/AutoreleasePool.cs
Show resolved
Hide resolved
eventually be when the Objective-C interop support is added.
|
@lambdageek I've applied the feedback to Mono. Let me know what you think. |
|
@akoeplinger yes, I believe so (yay!) |
This expands the current support where support was only added to
ThreadPoolthreads. Now all managed threadsor new native threads entering the runtimewill get anNSAutoreleasePoolallocated.New feature switch, "System.Threading.Thread.EnableAutoreleasePool", was created and the "System.Threading.ThreadPool.EnableDispatchAutoreleasePool" was removed.
Updated AutoReleaseTest for the new scenarios. Also added support for tests to pass Runtime Configuration Options to
corerun- uses the syntax found here - @LakshanF, @BruceForstall.This is a follow up PR started with #47592
Contributes to dotnet/macios#11256
/cc @rolfbjarne @jkotas @jkoritzinsky @elinor-fung