On Aug  6 18:54, Lavrentiev, Anton (NIH/NLM/NCBI) [C] via cygwin wrote:
> I have noticed a discrepancy between the process priority shown by
> "top" vs. what getpriority() returns.
> 
> I'm using the procps-based "top", so it reads the priority value from
> /proc/PID/stat.  The value gets there via code found in
> "fhandler_process.cc":
> 
>   /* The BasePriority returned to a 32 bit process under WOW64 is
>   apparently broken, for 32 and 64 bit target processes.  64 bit
>   processes get the correct base priority, even for 32 bit processes.
>   */ if (wincap.is_wow64 ()) priority = 8; /* Default value. */ else
>   priority = pbi.BasePriority;
> 
> But that's an inconsistent way of generating the value, because it is
> supposed to be the one that "getpriority()" returns.
> 
> Also, it looks like the higher value in "pbi.BasePriority" corresponds
> to a higher process priority, while Unix priority is higher when the
> value is less (20 - nice, generally).
> 
> It looks like it should have been done by calling a utility function,
> winprio_to_nice(GetPriorityClass(CurrentProcess())), and setting up
> both the priority field (as "NZERO + winprio_to_nice()") and the
> following "nice" field (which is currently set to permanent zero) with
> what winprio_to_nice() returns.

You seem to have worked it out already so please send a patch in
git format-patch foramt to the cygwin-patches mailing list.


Thanks,
Corinna

-- 
Corinna Vinschen
Cygwin Maintainer