David Fowler

Sockets are fine.

Then you need to be aware of the places that call SetResult or TrySetResult and potentially, they should be doing ThreadPool.QueueUserWorkItem or Task.Run. SignalR does this on .NET Framework https://github.com/SignalR/SignalR/blob/main/src/Microsoft.AspNet.SignalR.Core/Infrastructure/DispatchingTaskCompletionSource.cs

If there's no way to avoid it then you're in the bad situation described in the document. There's no workaround for needing to block using Task.Wait or Task.Result, nor is...

It's fine to use do background async work the trick is to understand that if you do async work, you're not blocking a running thread. The thread pool is very...

Generally, there's no performance benefit to using `Task.Run` in an ASP.NET Core application. You're already on a thread pool thread so you're just moving work off the existing thread pool...

How does that improve the situation? This is all about understanding tradeoffs. The higher is that each requests is conceptually already running inside of a Task.Run (not quite but roughly...

Yes, you can write it such that the background task is aware of the host lifetime, that's about it.

That doesn’t matter in this case but it does matter for the caching case so I’ll update that. Thanks for the feedback

That's a good point. I think we need to put this into a place in the docs that calls out guidance for server and client libraries in a table of...

Right there's no Udp abstraction as yet. It hasn't been designed