On 11/28/2012 08:11 PM, Nathan Scott wrote:
578 -- test harness expects monotonically increasing fd numbers
The openfds metric of pmcd is a bit misleading. It implies the number
of
currently open file descriptors, but it is reported based on the
value
of pmcd_hi_openfds (src/pmcd/src/pmcd.h) which is actually a high
water
mark of the highest ever open fd number. It is perhaps coincidentally
true that native fd numbers are monotonically increasing and that,
after
installation, the number of open file descriptors is also the number
of
the highest fd number as the test expects. However, with NSS/NSPR
enabled, while the native fd numbers are still in the range 0-1023,
the
NSPR ones are in the range 1024-2047 and so this assumption is no
longer
true.
I'm thinking that we should fix the metric to actually count the
number
of open fds (in the IPC table?). Can you see another solution?
Not really, as mentioned this metric is defined as follows:
$ pminfo -Tt pmcd.openfds
pmcd.openfds [highest PMCD file descriptor]
Help:
The highest file descriptor index used by PMCD for a Client or PMDA
connection.
So its name is a little misleading. I liked Franks suggestion though,
which was:
| Counting actual open fd's is not that hard even in general POSIX -
| iterate over the valid fd range, calling dup(i); if it returns >=0,
| close it and increment the openfds counter. With the IPC table, it
| sounds even easier and sounds like the way to go.
Its more expensive during the fetch method, but more accurate.
I think Ken may have written this code originally though, so be
good to again seek his thoughts before reimplementing it.
Frank's suggestion would be ok, if what we want is the number of
currently open fds, as would my suggest examiniation of the IPC table.
However, the help text for the metric clearly implies that it is the
highest fd number used by PMCD, i.e. the high water mark. According to
this definition, the current result returned for the NSS-enabled build
is technically correct, but not what the test case expects.
If this metric and the code which implements it were indeed written by
Ken, then I think we need some clarification from him regarding the
original intent before we can come up with the proper solution.
Dave
|