Hi guys,
----- Original Message -----
> On Fri, 2012-11-30 at 11:14 -0500, Dave Brolley wrote:
> > ...
> > 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.
>
> Yep, you can blame me ... 8^)>
>
> As far as I can recall (which is not far when you get to my age), the
> original motivation for this was to _cheaply_ collect a metric that
> would detect an obscure file descriptor leak problem.
>
> Using the number of open fd would be better than the maximum fd ever
> if the maximum is now very large in the NSS/NSPR case.
>
> I don't think iteration with dup() meets the "cheap" requirement.
>
> So provided you have closure of all the places open() and friends are
> called (as the current code does) _and_ closure over all the places
> ...
Been looking into this since its still the weekend over Dave's way.
With NSS we don't have direct access to these calls, its abstracted
away. I got a fair way into an implementation which does the dlsym
RTLD_NEXT trick to intercept the fd create/dup/teardown calls, but
it all fell over in the end due to complexities around open(). Its
varargs, is inline in glibc headers, and generally difficult.
So, backed off from that and went with a simpler model involving
extension of the existing instrumentation points. This turned out
to be much simpler, esp. once I understood exactly what Dave meant
with his comment about FD_SETSIZE earlier. Will go ahead with this
approach I think, keeping the existing semantics for pmcd.openfds.
One question which did come up that I'm looking for a second opinion
on - do we need max_seen_fd in src/pmcd/src/config.c? Doesn't this
duplicate the accounting also being done in PMCD_OPENFDS_SETHI()? I
wonder if the close-before-exec-loop could use pmcd_openfds_hi, and
could we remove max_seen_fd??
cheers.
--
Nathan
|