Following up with some discusson from a few months back,
where it was proposed that ProcessTable is a better name.
This data structure is definitely not a list ... if it
was one-dimensional it'd be a set, but in practice it has
much more in common with a two-dimensional table.
The Process table is a familiar operating system concept
for many people too so it resonates a little in that way
as well.
This commit refactors the Process and ProcessList structures such
they each have a new parent - Row and Table, respectively. These
new classes handle screen updates relating to anything that could
be represented in tabular format, e.g. cgroups, filesystems, etc,
without us having to reimplement the display logic repeatedly for
each new entity.
The 'comprisedValues' boolean property unnecessarily complicates the
drawing algorithms of Bar meters and Graph meters. Since the only user
of 'comprisedValues' is ZramMeter, it is better to rework the meter so
that it no longer needs 'comprisedValues'.
The 'values[ZRAM_METER_UNCOMPRESSED]' now stores the difference between
uncompressed and compressed data size.
Signed-off-by: Kang-Che Sung <explorer09@gmail.com>
The standard isnan() function is defined to never throw FP exceptions
even when the argument is a "signaling" NaN. This makes isnan() more
expensive than (x != x) expression unless the compiler flag
'-fno-signaling-nans' is given.
Introduce functions isNaN(), isNonnegative(), isPositive(),
sumPositiveValues() and compareRealNumbers(), and replace isnan() in
htop's codebase with the new functions. These functions utilize
isgreater() and isgreaterequal() comparisons, which do not throw FP
exceptions on "quiet" NaNs, which htop uses extensively.
With isnan() removed, there is no need to suppress the warning
'-Wno-c11-extensions' in FreeBSD. Remove the code from 'configure.ac'.
Signed-off-by: Kang-Che Sung <explorer09@gmail.com>
The recent split of machine-wide metric gathering from process metrics
gathering introduced a regression in the Linux running task accounting.
The way we extract this value from /proc/stat (which typically is used
for machine-wide metrics) conspired with a now-incorrectly placed init-
to-zero at the start of the per-process sampling, caused this value to
always be zero by the time the Tasks Meter used it.
Fix this by making it much more clear that Linux has this special case
handling of runningTasks.
Resolves#1256
Nathan Scott
Explorer09