Make DependentHandle public #54246
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change | ||||||
|---|---|---|---|---|---|---|---|---|
| @@ -0,0 +1,253 @@ | ||||||||
| // Licensed to the .NET Foundation under one or more agreements. | ||||||||
| // The .NET Foundation licenses this file to you under the MIT license. | ||||||||
|
|
||||||||
| using System.Runtime.CompilerServices; | ||||||||
| #if !DEBUG | ||||||||
| using Internal.Runtime.CompilerServices; | ||||||||
| #endif | ||||||||
|
|
||||||||
| namespace System.Runtime | ||||||||
| { | ||||||||
| /// <summary> | ||||||||
| /// Represents a dependent GC handle, which will conditionally keep a dependent object instance alive | ||||||||
| /// as long as a target object instance is alive as well, without representing a strong reference to the | ||||||||
| /// target object instance. That is, a <see cref="DependentHandle"/> value with a given object instance as | ||||||||
| /// target will not cause the target to be kept alive if there are no other strong references to it, but | ||||||||
| /// it will do so for the dependent object instance as long as the target is alive. | ||||||||
| /// <para> | ||||||||
| /// This type is conceptually equivalent to having a weak reference to a given target object instance A, with | ||||||||
| /// that object having a field or property (or some other strong reference) to a dependent object instance B. | ||||||||
| /// </para> | ||||||||
| /// </summary> | ||||||||
| /// <remarks> | ||||||||
| /// The <see cref="DependentHandle"/> type is not thread-safe, and consumers are responsible for ensuring that | ||||||||
| /// <see cref="Dispose"/> is not called concurrently with other APIs. Not doing so results in undefined behavior. | ||||||||
| /// <para>The <see cref="Target"/> and <see cref="Dependent"/> properties are instead thread-safe.</para> | ||||||||
| /// </remarks> | ||||||||
| public struct DependentHandle : IDisposable | ||||||||
|
||||||||
| { | ||||||||
| // ========================================================================================= | ||||||||
| // This struct collects all operations on native DependentHandles. The DependentHandle | ||||||||
| // merely wraps an IntPtr so this struct serves mainly as a "managed typedef." | ||||||||
| // | ||||||||
| // DependentHandles exist in one of two states: | ||||||||
| // | ||||||||
| // IsAllocated == false | ||||||||
| // No actual handle is allocated underneath. Illegal to get Target, Dependent | ||||||||
| // or GetTargetAndDependent(). Ok to call Dispose(). | ||||||||
| // | ||||||||
| // Initializing a DependentHandle using the nullary ctor creates a DependentHandle | ||||||||
| // that's in the !IsAllocated state. | ||||||||
| // (! Right now, we get this guarantee for free because (IntPtr)0 == NULL unmanaged handle. | ||||||||
| // ! If that assertion ever becomes false, we'll have to add an _isAllocated field | ||||||||
| // ! to compensate.) | ||||||||
| // | ||||||||
| // | ||||||||
| // IsAllocated == true | ||||||||
| // There's a handle allocated underneath. You must call Dispose() on this eventually | ||||||||
| // or you cause a native handle table leak. | ||||||||
| // | ||||||||
| // This struct intentionally does no self-synchronization. It's up to the caller to | ||||||||
jkotas marked this conversation as resolved.
Outdated
Show resolved
Hide resolved
|
||||||||
| // to use DependentHandles in a thread-safe way. | ||||||||
| // ========================================================================================= | ||||||||
|
|
||||||||
| private IntPtr _handle; | ||||||||
|
|
||||||||
| /// <summary> | ||||||||
| /// Initializes a new instance of the <see cref="DependentHandle"/> struct with the specified arguments. | ||||||||
| /// </summary> | ||||||||
| /// <param name="target">The target object instance to track.</param> | ||||||||
| /// <param name="dependent">The dependent object instance to associate with <paramref name="target"/>.</param> | ||||||||
| public DependentHandle(object? target, object? dependent) | ||||||||
| { | ||||||||
| // no need to check for null result: nInitialize expected to throw OOM. | ||||||||
| _handle = InternalInitialize(target, dependent); | ||||||||
| } | ||||||||
|
|
||||||||
| /// <summary> | ||||||||
| /// Gets a value indicating whether this handle has been allocated or not. | ||||||||
|
||||||||
| /// Gets a value indicating whether this handle has been allocated or not. | |
| /// Gets a value indicating whether this instance was constructed with | |
| /// <see cref="DependentHandle(object, object)"/> and has not yet been disposed. |
There was a problem hiding this comment.
IsAllocated is missing a similar thread-safety remark.
Outdated
There was a problem hiding this comment.
I couldn't attend the API review for this... what was the reason this design was decided on rather than:
public (object? Target, object? Dependent) TargetAndDependent { get; }?
There was a problem hiding this comment.
Jeremy mentioned that given that the method returned a tuple, it felt much more appropriate to him for it to be a method instead. I agree with that as well, and I'll also add that a tuple-returning property has never been used before in the BCL, whereas a tuple-returning method is more common today (eg. all the new Math APIs recently added). Jan said either was fine for him, so I just went with the method in this case 😄
There was a problem hiding this comment.
given that the method returned a tuple, it felt much more appropriate to him for it to be a method instead
Why? We have many properties that return structs with multiple properties. What makes a ValueTuple special?
There was a problem hiding this comment.
Can't talk for Jeremy specifically, what he said on stream was:
"Having a property that returns a tuple feels weird, it feels more method-y"
"[...] for reasons that I can't articulate, maybe artistic style, this feels more like a method than a property"
"[...]
TargetAndDependentshould be a method, not a property. It feels really weird as a property".
For more on his part, you'd have to ask him 🙂
On my end, I can say that one of the reasons why I really feel like it should be a method is that in this case we're not conceptually returning an entity (such as a color, which has multiple channels), but two separate entities. The C# guideline often refer to properties as each representing "one entity", which is the case here as well, with Target and Dependent. As in, we have a property for each entity, and if you want to get both of them together, we then have a method that retrieves both entities and returns them. Having both a property for each entity and also a property for both looks really weird to me. And also the fact that we've just never used a value-tuple in a property before, while we have in methods. I just really agree with Jeremy that a method just feels right in this case, is all 😄
There was a problem hiding this comment.
Maybe we should just drop this method/property. The motivation for this method was that it helps to avoid certain types of race conditions: #19459 (comment) . These race conditions can be trivially avoided by the caller using GC.KeepAlive too, so it is there just for convenience.
This type of race conditions should be mentioned in the documentation in any case. Given that this is advanced type, I do not think that there is a huge difference between recomending to use GC.KeepAlive vs. recomending to use the tuple returning method.
There was a problem hiding this comment.
Yup, was just going through the VM trying to understand exactly how that hack actually worked 😄
I wasn't aware that both GCHandle and DependentHandle still used the same OBJECTHANDLE struct in the VM (GCHandleManager::CreateGlobalHandleOfType and GCHandleStore::CreateDependentHandle). After going through the code and having a read at this paragraph I think I get the general gist of that seemingly magic trick, will go try to make that change you suggested. One never stops learning cool stuff by contributing to the runtime! 🙌
There was a problem hiding this comment.
@jkotas After checking it looks like that with Andy's recent jump threading changes (#46257), the JIT can now correctly skip the second null check if you get Target and Dependent sequentially (given that handle just gets read to a register anyway), which after the optimization to nGetPrimary would've been the only remaining advantage for GetTargetAndDependent(). I think with that then the codegen for both things should be pretty much the same, so if you prefer to remove that API I guess it should be safe to do so now without having performance overhead for public consumers? Happy to add those remarks about GC.KeepAlive as well 🙂
There was a problem hiding this comment.
Yes, I would vote to remove the tuple returning APIs and just document the race conditions to be careful about.
There was a problem hiding this comment.
Removed in 9c23a947ce5da21fb6169b6dae16a38f1412e8e9 and added the documentation about GC.KeepAlive 👍
There was a problem hiding this comment.
I still see it in the PR. Did you intend to remove it?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The details are nice, but this is way too long for a summary, which should be at most one sentence (it's what pops up in IntelliSense for a method). Can you move everything but the first sentence to remarks, editing it appropriately? Thanks!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fixed this in c463d54, as well as all the other review comments below 🙂