David Riley wrote:
> On Sep 25, 2020, at 3:13 PM, Todd C. Miller wrote:
> >
> > On Fri, 25 Sep 2020 13:58:01 -0500, Scott Cheloha wrote:
> >
> >> `found' serves as a boolean here. I'd prefer to simple and set it to
> >> 1 instead of incrementing it when we find what we're looking for.
> >
>
On Sep 25, 2020, at 3:13 PM, Todd C. Miller wrote:
>
> On Fri, 25 Sep 2020 13:58:01 -0500, Scott Cheloha wrote:
>
>> `found' serves as a boolean here. I'd prefer to simple and set it to
>> 1 instead of incrementing it when we find what we're looking for.
>
> Makes sense to me, the use of var++
We can't have 2 billion processes to reach a wrap.
But I agree, it seems quite wrong, and seems better to just observe
match rather than count.
Scott Cheloha wrote:
> `found' serves as a boolean here. I'd prefer to simple and set it to
> 1 instead of incrementing it when we find what we're lo
On Fri, 25 Sep 2020 13:58:01 -0500, Scott Cheloha wrote:
> `found' serves as a boolean here. I'd prefer to simple and set it to
> 1 instead of incrementing it when we find what we're looking for.
Makes sense to me, the use of var++ instead of var=1 is old-school
style ;-)
- todd
`found' serves as a boolean here. I'd prefer to simple and set it to
1 instead of incrementing it when we find what we're looking for.
ok?
Index: kern_resource.c
===
RCS file: /cvs/src/sys/kern/kern_resource.c,v
retrieving revision
Diff below is mostly a refactoring to reduce the amount of spaghetti in
the scheduler logic:
- resetpriority() is renamed to setpriority() and is now the only places
that sets `p_estcpu' and `p_usrpri'. These two fields represent the
priority of a running process. They should be i
Hi,
I found in top(1) a call to nice(3) that I think that should be changed to
setpriority(2). When given the -q flag the manpage claims that top will be
reniced to -20.
This is implemented trough nice(3) taking advantage that a program are loaded
with 0 niceness priority, so decrementing 20
