There has been a renewed interest in architectural designs for threading and I/O in the last few years. Thread-per-core architectures and io_uring being of particular relevance. Popular in high throughput, low latency applications like web servers and databases, areas .NET is good at these days.
While Rust is generally taking the lead here - both in activity and performance - authors of similar software in .NET (e.g. Kestrel/ASP.NET Core/YARP, Garnet, Orleans, RavenDB) looking to experiment or offer these architectures to their users would quickly find it infeasible today due to a few simple realities: tight coupling to the thread pool in the async and I/O internals, and a strong doctrine of ConfigureAwait(false)
use in libraries.
These prevent alternative designs from maintaining workload affinity. Even if I/O is not a concern and ConfigureAwait(false)
would not exist, achieving significant performance gains may still be challenging. TaskSchedulers and SynchronizationContexts are genera