Ensure that OptionsCache only permits creating a single options instance per name

[madelson]

This incurs an extra delegate allocation, but only on instance creation.

fix #79529

[ghost]

Tagging subscribers to this area: @dotnet/area-extensions-options
See info in area-owners.md if you want to be subscribed.

Issue Details

---

This incurs an extra delegate allocation, but only on instance creation.

fix #79529

Author:	madelson
Assignees:	-
Labels:	area-Extensions-Options
Milestone:	-

[tarekgh]

@madelson the new test is failing on WASM runs.

13:29:00] fail: [FAIL] Microsoft.Extensions.Options.Tests.OptionsMonitorTest.InstantiatesOnlyOneOptionsInstance
[13:29:00] info: Assert.True() Failure
[13:29:00] info: Expected: True
[13:29:00] info: Actual:   False
[13:29:00] info:    at Microsoft.Extensions.Options.Tests.OptionsMonitorTest.InstantiatesOnlyOneOptionsInstance()
[13:29:00] info:    at System.Reflection.MethodInvoker.InterpretedInvoke(Object obj, IntPtr* args)
[13:29:00] info:    at System.Reflection.MethodInvoker.Invoke(Object obj, IntPtr* args, BindingFlags invokeAttr)
[13:29:00] info: Finished:    Microsoft.Extensions.Options.Tests.dll

[madelson]

@tarekgh any initial thoughts as to why this would fail on wasm? I'm not too familiar with aspects of that runtime that might be different. Would you expect all the main components the test uses to work as they do on desktop (threads, Barrier, AutoResetEvent, etc)?

[tarekgh]

@madelson this may be related to https://github.com/WebAssembly/threads. CC @lewing if has more information here. I would suggest excluding the new test from WASM runs.

[lewing]

The issue is that you can't do a synchronous wait in the regular wasm runtime. You can either exclude the test or rewrite it to as an async test and await the tasks.

[madelson]

Thanks @tarekgh @lewing .

This test is trying to replicate a parallel concurrency issue and is using Barrier.SignalAndWait() and AutoResetEvent.Wait() to force the concurrency. Because we're injecting these into sync flows they can't be replaced with async. Furthermore, on a platform that doesn't support true multi-threading the underlying problem should not reproduce anyway.

For these reasons, I think it makes sense to skip the test on wasm. Let me know if you disagree.

[madelson]

@tarekgh does the build analysis look good now? Only shows a known error which seems unrelated.

[tarekgh]

Thanks @madelson! LGTM.

[tarekgh]

/backport to release/7.0

[github-actions]

Started backporting to release/7.0: https://github.com/dotnet/runtime/actions/runs/3833598902