On Fri Dec 1 19:43:32 2023 +0000, Marc-Aurel Zent wrote:
Hm it seems to me like every process can set its own niceness to [limit, 19]. Making the assumption that the hard limit for wineserver and wine processes are the same (which it probably always will be unless the user did something special), there probably is no need to send back the nice limit of the target process, only for each to raise its limit. For CAP_SYS_NICE (or euid 0) though the target process limit does not matter at all, so taking the -20 limit of the server there should be fine as well. Would be a partial revert of https://gitlab.winehq.org/wine/wine/-/merge_requests/4551/diffs?commit_id=89... and adjusting the logic to go from [limit, -limit] to [limit, 19], unless they have to be symmetrical?
Yeah I think it's probably fine to assume that the rlimit for every process will be the same, and if it's not `SetThreadPriority` will just return an error.
The symmetry was there to make the range mapping easier, as well as to keep the symmetry of Windows thread priorities. I think it's best to keep it like this as it gives control over both the lowest and highest priority at the same time.