Further fix for CowArray to prevent using the refcount from GC #10788
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
While in a GC finalizer:
See #10785 for the first fix, which did some of this, but not for the refcount.
technically, we really should just ban use of the array from inside a finalizer. But this should be enough to get past the segfaults we are seeing.
This does mean that any
CowArray!GcPolicy
which has a reference from a finalized block, will have extra references that never go away. This is OK, because, if you write to the array, you will make a copy. And then there is now a refcount of 1 again, and the original can truly become garbage. If you read from it, nothing is different.In general, we should probably examine why we need the complication of this scheme here. Obviously, it has not been fully understood in the context of how the GC works, and It's an internal type, which is only used in std.uni...