Skip to content

[coreclr] Support for NSAutoreleasePools has now been implemented for background threads for both MonoVM and CoreCLR. Fixes #11256.#11749

Merged
rolfbjarne merged 4 commits intodotnet:mainfrom
rolfbjarne:dotnet-autorelasepools-background-threads
Jun 2, 2021
Merged

[coreclr] Support for NSAutoreleasePools has now been implemented for background threads for both MonoVM and CoreCLR. Fixes #11256.#11749
rolfbjarne merged 4 commits intodotnet:mainfrom
rolfbjarne:dotnet-autorelasepools-background-threads

Conversation

@rolfbjarne
Copy link
Member

@rolfbjarne rolfbjarne commented May 31, 2021

Fixes #11256.

… background threads for both MonoVM and CoreCLR.
@rolfbjarne rolfbjarne added not-notes-worthy Ignore for release notes run-dotnet-tests Run all the .NET tests labels May 31, 2021
@rolfbjarne rolfbjarne changed the title [coreclr] Support for NSAutoreleasePools has now been implemented for background threads for both MonoVM and CoreCLR. [coreclr] Support for NSAutoreleasePools has now been implemented for background threads for both MonoVM and CoreCLR. Fixes #11256. May 31, 2021
// Strangely enough there seems to be a race condition here, not all threads will necessarily
// have completed the autorelease by this point. Some should have though, so assert that the object
// was released on at least one thread.
Assert.That ((int) obj.RetainCount, Is.LessThan (10), "RC");
Copy link
Contributor

Choose a reason for hiding this comment

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

Use count, which could be made a const, instead of 10.

so assert that the object was released on at least one thread.

Just by reading the NSAutoreleasePoolInThread I'm not convinced it shows the feature to be working.

E.g. If only done by a single thread (out of 10) then the issue might not be a race. It could be that it somehow get called just once.

If you use count - 1 then we know (but reading the test, not the code) this works on multiple (not just the first) threads.

Copy link
Member Author

Choose a reason for hiding this comment

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

@spouliot

Use count, which could be made a const, instead of 10.

Done.

If you use count - 1 then we know (but reading the test, not the code) this works on multiple (not just the first) threads.

I decided to be braver and used count / 2 instead 😄

@vs-mobiletools-engineering-service2

This comment has been minimized.

@@ -244,8 +244,6 @@
void
xamarin_install_nsautoreleasepool_hooks ()
Copy link
Member

Choose a reason for hiding this comment

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

Why is this empty?

Copy link
Member Author

Choose a reason for hiding this comment

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

@dalexsoto Because nothing needs to happen where - there's another version of this method for MonoVM:

https://github.com/xamarin/xamarin-macios/blob/5a0600491c05e34cdc40c765ea4a18c5debab484/runtime/monovm-bridge.m#L283-L290

I've added a comment to explain this.

{
// https://github.com/xamarin/xamarin-macios/issues/11256
fprintf (stderr, "TODO: add support for wrapping all threads with NSAutoreleasePools.\n");
// No need to do anything here for CoreCLR.
Copy link
Member

Choose a reason for hiding this comment

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

it'd be good to do the same for Mono too in .NET6 so we're consistent (and not rely on the mono profiler hook to install this)

Copy link
Member Author

Choose a reason for hiding this comment

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

@akoeplinger would that require any changes in Mono that we have to wait for? Or is that already implemented?

Copy link
Member

Choose a reason for hiding this comment

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

@rolfbjarne it should already be implemented

Copy link
Member Author

Choose a reason for hiding this comment

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

@rolfbjarne it should already be implemented

Ok, filed: #11788

@vs-mobiletools-engineering-service2

This comment has been minimized.

@vs-mobiletools-engineering-service2
Copy link
Collaborator

✅ [PR Build] Tests passed on Build. ✅

Tests passed on Build.

API diff

✅ API Diff from stable

View API diff

API & Generator diff

API Diff (from PR only) (no change)
Generator Diff (no change)

GitHub pages

Results can be found in the following github pages (it might take some time to publish):

🎉 All 108 tests passed 🎉

Pipeline on Agent XAMBOT-1104.BigSur'
Merge 42a2feb into 1c60b17

@rolfbjarne rolfbjarne merged commit 071ac64 into dotnet:main Jun 2, 2021
@rolfbjarne rolfbjarne deleted the dotnet-autorelasepools-background-threads branch June 2, 2021 05:41
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

not-notes-worthy Ignore for release notes run-dotnet-tests Run all the .NET tests

Projects

None yet

Development

Successfully merging this pull request may close these issues.

CoreCLR: NSAutoreleasePool for every thread

5 participants