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.

Sign up for GitHub

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

Jump to bottom

TUI's device thread consumes a full CPU core, even when nothing is happening #5

Open
rrbutani opened this issue Feb 16, 2020 · 2 comments
Open

TUI's device thread consumes a full CPU core, even when nothing is happening #5

rrbutani opened this issue Feb 16, 2020 · 2 comments
Assignees
@rrbutani

Comments

@rrbutani
Copy link
Member

This happens because we constantly poll for incoming messages.

We can maintain the level of responsiveness we want while also not being extremely wasteful; it's time to implement some kind of back off on the device thread.
@rrbutani rrbutani self-assigned this Feb 16, 2020
@rrbutani
Copy link
Member Author

If we're okay pulling in another dep, this looks pretty good.

@rrbutani
Copy link
Member Author

As mentioned in a commit message:

Our situation is a little weird because the downside of erring on the side of sleeping for too long isn't just lag/a decrease in responsivity for the user; instead it also means that the controller thread will consume massive amounts of CPU since it's effectively spinning waiting on the response.

In the future we may want to either:

  • have the Controller back off too instead of just spinning
  • provide a blocking get method on the Transport trait that the Controller will use

I like the latter solution.

rrbutani referenced this issue in ut-utp/core Feb 16, 2020
@rrbutani
tui: add primitive backoff support to the Device Thread
078eb0a 
This is untuned and also is currently not exponential.

Our situation is a little weird because the downside of erring on the side of sleeping for too long isn't just lag/a decrease in responsivity for the user; instead it also means that the controller thread will consume massive amounts of CPU since it's effectively spinning waiting on the response.
So, this is a somewhat elaborate balancing act.

re: #52
rrbutani referenced this issue in ut-utp/core Mar 10, 2020
@rrbutani
tui: add primitive backoff support to the Device Thread
aa16511 
This is untuned and also is currently not exponential.

Our situation is a little weird because the downside of erring on the side of sleeping for too long isn't just lag/a decrease in responsivity for the user; instead it also means that the controller thread will consume massive amounts of CPU since it's effectively spinning waiting on the response.
So, this is a somewhat elaborate balancing act.

re: #52
@jer-zhang jer-zhang transferred this issue from ut-utp/core May 21, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@rrbutani rrbutani

Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
1 participant
@rrbutani