Adding Priority Scheduling feature to the subprocess

[TimeHorse]

On Feb 20, 10:15 pm, "Terry Reedy" <tjre... at udel.edu> wrote:
> | Because UNIX uses priorities between +20 and -20 and Windows, via
> | Process and Thread priorities, allows settings between 0 and 31, a
> | uniform setting for each system should be derived.  This would be
> | accomplished by giving process priority in terms of a floating-point
> | value between 0.0 and 1.0 for lowest and highest possible priority,
> | respectively.
>
> I would rather that the feature use the -20 to 20 priorities and map that
> appropriately to the Windows range on Windows.

The problem as I see it is that -20 to +20 is only just over 5 bits of
precision and I can easily imagine an OS with many more than just 5
bits to specify a process priority.  Of course, the os.getpriority and
os.setpriority, being specific to UNIX, WOULD use the -20 to +20
scale, it's just the generic subprocess that would not.  But for a
generic priority, I like floating point because it gives 52 bits of
precision on most platforms.  This would allow for the most
flexibility.  Also, 0.0 to 1.0 is in some ways more intuitive to new
programmers because it can be modeled as ~0% CPU usage vs. ~100% CPU
usage, theoretically.  Users not familiar with UNIX might OTHO be
confused by the idea that a lower priority number constitutes a
"higher priority".

Of course, the scale used for p in Popen(...).setPriority(p) is really
not an important issue to me as long as it makes sense in the context
of priorities.  Given that os.setpriority and Popen(...).setPriority
have virtually the same name, it would probably be better to rename
the later to something a bit less prone to confusion.  Alternatively,
it would not be unreasonable to design setPriority (and getPriority
correspondingly) such that under UNIX it takes 1 parameter, -20 to +20
and under Windows it takes 2 parameters, second one optional, where
the Windows API priorities are directly passed to it (for getPriority,
Windows would return a Tuple pair corresponding to Priority Class and
Main Thread Priority).  However, I personally prefer a unified
definition for subprocess.py's Priority since there already is or will
be direct os-level methods to accomplish the same thing in the os-
native scale.

Anyway, thanks for the input and I will make a note of it in the PEP.
Other than the generic Property ranges, do you see any other issues
with my proposal?

Jeffrey.