On Fri Mar 7 23:21:57 2025 +0000, Marc-Aurel Zent wrote:
Yeah I originally also read that piece of documentation first (and the current nomenclature used in Wine makes sense with it), but the more I looked into how things actually work and not only ntdll constants, but also all structures fields and functions (some even documented like [KeSetPriorityThread](https://learn.microsoft.com/en-us/windows-hardware/drivers/ddi/wdm/nf-wdm-ke...) or [KeSetBasePriorityThread](https://learn.microsoft.com/en-us/windows-hardware/drivers/ddi/ntddk/nf-ntdd...)) consistently use the terms in exactly the opposite way. Naming them like that makes everything line up perfectly AFAICT, so I think the rename is worth it here. I also wouldn't mind renaming the old thread priority to `priority_level` like you suggested per se, which would be the same amount of work... I believe the way it is in this MR now though is nicer and more consistent.
After digging a bit deeper, the way it actually works is ``` Thread Priority = Process Base Priority + Thread Base Priority ``` using NT terminology, so I think it makes sense to keep mirroring that server-side.
Also process BasePriority is something that can be set AFAICT as well, making the rabbit hole go even deeper here (but this MR is already too large, so I will postpone that for the next part).
If I had known when creating part one of this series what I know now, I would have probably also named all priorities, be they thread or process to `priority` or `base_priority` depending on what they actually represent.