-
Notifications
You must be signed in to change notification settings - Fork 152
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add JoinableTaskFactory integration #886
Conversation
This avoids deadlocks that RPC would otherwise introduce by carrying a `JoinableTask` token across RPC so that when/if the RPC call ever makes it back to the original AppDomain (or never leaves it) such that the callee needs the main thread, it will be able to reach it if the caller owns the main thread.
this.joinableTaskTokenWithoutJtf.Value = parentToken; | ||
} | ||
|
||
if (this.JoinableTaskFactory is null || parentToken is null) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If there is a JTF instance but no token was provided in the header, should we still use JTF to dispatch for the benefit of the current process? (although I am not sure what benefit there would be)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Lifeng and I couldn't think of any benefit in doing so. But there is a non-zero overhead from doing so. Thus, we only do it when we feel it's justified by skipping when there is no parent token.
microsoft#886 introduced JsonRpc-JoinableTaskFactory integration, but did not document it.
This avoids deadlocks that RPC would otherwise introduce by carrying a
JoinableTask
token across RPC so that when/if the RPC call ever makes it back to the original AppDomain (or never leaves it) such that the callee needs the main thread, it will be able to reach it if the caller owns the main thread.