Get InvocationList of MulticastDelegate without any allocation

[RamType0]

Background and Motivation

Currently,we have an API to invocation list of MulticastDelegate,it is MulticastDelegate.GetInvocationList().

It allocates array every time we call it. And maybe that's why we have internal HasSingleTarget property in it.

We need handsome,and performant API.

Proposed API

public class Delegate
{
    // Existing API
    // public virtual System.Delegate[] GetInvocationList();

    // Returns whether the delegate has a single target. It is a property to highlight that it is guaranteed 
    // to be a very cheap operation that is important for set of scenarios addressed by this proposal.
    // Alternative names: HasSingleTarget, IsTrueMulticast (inverted condition), HasSingleElementInvocationList
    public bool IsSingle { get; }

    // Returns length of the invocation list. It is a method to highlight that it may not be a very cheap operation.
    // This method is optional part of the proposal for completeness. It is fine to omit it from the approved shape.
    public int GetInvocationListLength();

    // Returns invocation list enumerator
    public static InvocationListEnumerator<TDelegate> EnumerateInvocationList<TDelegate>(TDelegate d) where TDelegate : Delegate;

    // The shape of this enumerator matches existing StringBuilder.ChunkEnumerator and Activity.Enumerator
    // Neither of these existing enumerators implement IEnumerable and IEnumerator. This can be changed. 
    // Q: How are we deciding whether enumerators like this should implement IEnumerable and IEnumerator?
    // Note that implementing these interfaces makes each instantiation of the type more expensive, so it is a tradeoff.
    public struct InvocationListEnumerator<TDelegate> where TDelegate : Delegate
    {
        public TDelegate Current { get; }
        public bool MoveNext();

        // EditorBrowsable to match existing StringBuilder.ChunkEnumerator and Activity.Enumerator
        [EditorBrowsable(EditorBrowsableState.Never)] // Only here to make foreach work
        public InvocationListEnumerator<TDelegate> GetEnumerator() => this;
    }
}

---

Original rejected proposal

public ReadOnlySpan<Delegate> InvocationList => delegates == null ? MemoryMarshal.CreateSpan(this,1) : delegates;

[jkotas]

However, if there is a value with exposing a property or method for GetInvocationList().Length that would be fine

@terrajobst What would be a good API name for that?

As @weltkante pointed out, special casing the single-cast delegate fast path is fairly common. It would be nice to introduce proper API to replace the solutions based on private reflection:

• https://github.com/dotnet/runtime/blob/df885e7c2f2c5716e49d069675c2578c07924c5e/src/mono/System.Private.CoreLib/src/System/MulticastDelegate.cs#L53-L65

• https://github.com/deniszykov/WebSocketListener/blob/344cec982803790cf4b95ac207865871a6fdc2a0/vtortola.WebSockets/Tools/DelegateHelper.cs#L29-L30

• https://github.com/mgravell/Pipelines.Sockets.Unofficial/blob/6703efc310131037ee55b3136ff0d2d9e0df1e3f/src/Pipelines.Sockets.Unofficial/Delegates.cs#L30-L35

[terrajobst]

@jkotas

@terrajobst What would be a good API name for that?

The objection to exposing the proposed properties was raised by @GrabYourPitchforks, so I let him speak to the details here.

My understanding was that InvocationCount would return the number of elements the iterator would produce (equivalent to GetInvocationList().Length) and that the Boolean IsSingleInvocation would be equivalent to InvocationCount == 0, so those names seemed reasonable.

In order for me to propose better names is dependent upon understanding the desired semantics.

[jkotas]

My understanding was that InvocationCount would return the number of elements the iterator would produce

Yes, that's correct.

Exposing InvocationCount with assumption that it is a fast O(1) operation locks us into the current internal delegate implementation. This assumption would be broken if we were to change the internal delegate implementation to a different data structure that does not allow fast O(1) length operation. (The internal data structure used by delegates was changed at least once in .NET runtime history.) This lock-in is not a showstopper, I am just pointing out the downside of exposing full InvocationCount when the API use cases only need to check for == 1.

[terrajobst]

Marking the API as I forgot to do that in the meeting 🤦

[halter73]

I was concerned that Delegate.InvocationCount might be misconstrued to mean the number of times the Delegate has been invoked.

[jkotas]

I was concerned that Delegate.InvocationCount might be misconstrued

Renamed to GetInvocationListLength() for clarity.

[jkotas]

I have updated the proposal at the top with the feedback so far. Any comments?

[weltkante]

I have updated the proposal at the top with the feedback so far. Any comments?

IsSingle is probably meant to be a boolean?

[jkotas]

I think this is ready for next round of API review discussion.

[bartonjs]

Video

• We discussed whether the new enumerator needs to declare IEnumerable and/or IEnumerator, and we feel that's not necessary given that GetInvocationList() is already a Linq.Enumerable-friendly version of the data.
• EnumerateInvocationList being static was questioned, and it was answered that it was to make the enumerated values be typed as the input type, rather than going back to just System.Delegate.
• IsSingle got changed to the first alternative proposal of HasSingleTarget
• GetInvocationListLength was removed, pending a more concrete need in the future.

public class Delegate
{
    // Existing API
    // public virtual System.Delegate[] GetInvocationList();

    // Returns whether the delegate has a single target. It is a property to highlight that it is guaranteed 
    // to be a very cheap operation that is important for set of scenarios addressed by this proposal.
    public bool HasSingleTarget { get; }

    // Returns invocation list enumerator
    public static InvocationListEnumerator<TDelegate> EnumerateInvocationList<TDelegate>(TDelegate d) where TDelegate : Delegate;

    // The shape of this enumerator matches existing StringBuilder.ChunkEnumerator and Activity.Enumerator
    // Neither of these existing enumerators implement IEnumerable and IEnumerator. This can be changed. 
    // Q: How are we deciding whether enumerators like this should implement IEnumerable and IEnumerator?
    // Note that implementing these interfaces makes each instantiation of the type more expensive, so it is a tradeoff.
    public struct InvocationListEnumerator<TDelegate> where TDelegate : Delegate
    {
        public TDelegate Current { get; }
        public bool MoveNext();

        // EditorBrowsable to match existing StringBuilder.ChunkEnumerator and Activity.Enumerator
        [EditorBrowsable(EditorBrowsableState.Never)] // Only here to make foreach work
        public InvocationListEnumerator<TDelegate> GetEnumerator() => this;
    }
}

[weltkante]

I've wanted to try out the new APIs but they don't seem to appear in the daily builds, am I missing something? Sorry if there's known delays between PRs and daily builds, didn't see anything being mentioned.

[jkotas]

Yes, .NET SDK runs behind dotnet/runtime. You can check https://github.com/dotnet/installer/blob/main/eng/Version.Details.xml#L30 to see the dotnet/runtime commit that is in the SDK.

[jkotas]

Also https://github.com/dotnet/runtime/blob/main/docs/project/dogfooding.md#advanced-scenario---using-a-daily-build-of-microsoftnetcoreapp has instructions for how to get daily builds of dotnet/runtime without waiting for the bits to flow to .NET SDK.