Guidance for using JoinableTaskFactory in DotNet application? #1236
Replies: 1 comment 2 replies
-
You didn't mention what kind of application you're building.
This is incorrect. .NET apps are no different from .NET Framework or any other app platform in this respect. Every app has an entrypoint thread, and most or all apps with a GUI have a UI thread, which tends to be the entrypoint thread, or what we typically call a main thread. If your app has a main thread, you should first create a single-threaded SynchronizationContext on it and then create one JoinableTaskContext on that. You should not ever have more than one |
Beta Was this translation helpful? Give feedback.
-
Hi, I am planning to use JoinableTaskFactory from this library to address sync-over-async anti-patterns in a existing codebase to prevent deadlocks.
I am still a bit confused regarding the JoinableTaskContext, and would appreciate some guidance. Should it be instantiated for each request, or should it be assigned to a specific thread from the threadpool? (since I believe there isn't technically a UI/main thread in DotNet apps)
Due to the above confusion, I went with the above pattern as a provider for the JoinableTaskContext.
However as I ran through a few benchmark tests, the results seemed a bit odd. Looks like for the nested cases, the JTF actually results in degraded performance. (While i think the chance of using nested factory is low, the possibility cannot be ruled out)
Could anyone provided some clarification here. Thanks in advance
Below I will attach the BenchmarkCode
Beta Was this translation helpful? Give feedback.
All reactions