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

Support process niceness assignments even if foreground: or background: is set to None #12

Closed
techsy730 opened this issue Feb 8, 2022 · 2 comments · Fixed by #13
Closed

Comments

@techsy730
Copy link
Contributor

techsy730 commented Feb 8, 2022

For my machine, I don't want system76-scheduler to mess with my niceness by default. Only when it explicitly matches a command name in some file in system76-schedule/assignments.

So to do this, I used /etc/system76-schedule/assignments/my_assignments.ron, and set my /etc/system76-schedule/config.ron to:

(
background: None,

foreground: None,
)

system76-schedule correctly interpreted this a not touching background or foreground process niceness by default.
Unfortunately, is also tells it to not touch background or foreground process niceness at all.

The behavior I expected was "Does not touch background or foreground process, unless there is a match in the assignments."

So can that be a thing?
If people are relying on the old behavior (None telling system76-scheduler to skip that category entirely), then perhaps some new value we can assign that it will know "Don't touch it, but still look at the assignments and take action if found there". Like

(
background: Some<AssignmentsOnly>,
// Where AssignmentsOnly is an i8 constant that is way outside the valid nice range, or some other type,
// that system76-scheduler will give this treatment to if it sees it.

foreground: Some<AssignmentsOnly>,
)

or something.

@mmstick
Copy link
Member

mmstick commented Feb 8, 2022

It's not intended for the assigned priorities to be ignored.

@techsy730
Copy link
Contributor Author

Ah, then maybe the issue is in Main.rs in SetForegroundProcess. More specifically, where config.foreground is read and unpacked

The thing part that loops over the PIDs in the foreground and compares against assignments is in the if block if let Some(foreground_priority) = config.foreground {.
Which I think means that if config.foreground == None, that assignment checks never get done.

Sadly I don't have a good Rust dev environment at the moment, because otherwise I would make a PR.

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

Successfully merging a pull request may close this issue.

2 participants