Skip to content
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

review all the request handlers and make sure nothing is running directly on the main thread. #1206

Open
alanrenmsft opened this issue May 6, 2021 · 2 comments
Assignees
Labels

Comments

@alanrenmsft
Copy link
Contributor

No description provided.

@alanrenmsft
Copy link
Contributor Author

@alanrenmsft alanrenmsft self-assigned this May 7, 2021
@alanrenmsft alanrenmsft added the bug label May 7, 2021
@Charles-Gagnon
Copy link
Contributor

So @alanrenmsft the concern I had with just returning TaskCompleted for that instance was I just want us to make sure that we're ok with having each message handler determine whether they're blocking or non-blocking and to need to do that by spinning off a separate thread and then just returning immediately. Right now all messages are blocking which I'm not sure is really made clear anywhere so mistakes like this can happen. Might be worth looking at a couple of other options :

  1. Make messages non-blocking by default. I'm not even sure why message handlers are blocking in the first place - are there any scenarios that we need that which isn't just solved by the fact that on the calling side it needs to wait for a response to be sent anyways
  2. Have some sort of flag to the set handler method that tells it whether to be blocking or not - just to make it more clear

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants