Added note about caching to DllImportResolver

[gfoidl]

Summary

See dotnet/runtime#86088 for context

/cc: @jkotas (thanks for your pointers)

[AaronRobinsonMSFT]

/cc @gewarren

[jkotas]

The resolver delegate is called every time when a PInvoke call is done.

This does not look right.

The resolver is called first time a PInvoke call is done. It is not called every time PInvoke call is done.

[gewarren]

Also please change everytime to "every time".

[gfoidl]

The resolver is called first time a PInvoke call is done. It is not called every time PInvoke call is done.

Ah, I mis-interpreted the (debug) output from dotnet/runtime#86088 (comment) and from my test program.

test program

using System.Reflection;
using System.Runtime.InteropServices;

for (int i = 0; i < 10; ++i)
{
    string version = Native.GetVersion();
    int versionNumber = Native.cairo_version();

    Console.WriteLine($"{version}\t{versionNumber}");
}

internal static unsafe partial class Native
{
    [LibraryImport("cairo")]
    internal static partial int cairo_version();

    [LibraryImport("cairo")]
    internal static partial sbyte* cairo_version_string();
    public static string GetVersion() => new string(cairo_version_string());

    static Native()
    {
        NativeLibrary.SetDllImportResolver(Assembly.GetExecutingAssembly(), static (libraryName, assembly, searchPath) =>
        {
            Console.WriteLine($"DllResolver called for lib {libraryName}");

            return 0;
        });
    }
}

In a larger project I saw a call to the resolver quite often, but actually it's called the first time a native method is called, not every time.

So for $n$ entrypoints for the same library, the resolver will be called $n$ times.
And to avoid repeated building of paths, etc. the returned handle can be cached e.g. in a static field, as long the library is not unloaded.

Now I understand how it works. Maybe the woding isn't perfect here, but I'll open a PR that corrects this.

[jkotas]

Runtime does not take any locks around the resolver callback, so the resolver callback can be called from multiple threads at the same time for the same entrypoint.

[jkotas]

It is fine to cache the handle, as long as the consuming code does not call

This looks misleading without the context from the discussion that this was copied from.

Where is it fine to cache the handle? What is the consuming code?

[jkotas]

@gfoidl Could you please open a follow up PR to adjust the wording? I am sorry this was merged before I got a chance to take a look.

[gfoidl]

PTAL at #11865 (and help for better wording).