On 15/02/15 12:28, Frank Ch. Eigler wrote:
Yeah, it's a textbook example. I was thinking at one point that the
AF* functionality could be recast as something occurring synchronously
rather than asynchronously. For example, we could define redefine the
__pmAF* functions so that callbacks occur only as/after libpcp
functions are about to return to the application. (A new __pmAFwait()
could serve pmlogger's non-busy-looping.)
Maybe. But pmlogger is sitting in select waiting for an AF timer event
_or_ i/o on the control port (via pmlc) ... not sure how a __pmAFwait()
could be helpful here.
Anyway, for the specific case of pmlogger, I've fixed this is the proper
POSIX.1 way, and made all of the AF callback routines restricted to be
async-signal-safe (indeed they call _no_ other routines). All of the
work is deferred to the main loop once the global state change(s) are
noticed.
I've also added documentation in the pmaf(3) man page to describe the
required restrictions on the func() routine passed to pmAFregister().
These changes have passed a full QA (including recreating all the QA
archives that are not checked in), are in my next batch of commits.
I think the number of places we need to address these issues is
sufficiently small that we should audit and fix as required as a first
attempt, without changing libpcp abi/api/semantics if possible.
For reference here are the places __pmAFregister() is called:
perl/PMDA/local.c - this is an issue, see bug#1069
pmdas/bash/bash.c - safe
pmdas/linux_proc/proc_pid.c - would need a libpcp_pmda change to allow
some safe but async hook from pmdaMain() back into the pmda code, or use
its own main loop, like some other pmdas do (e.g. logger, trace)
pmdas/hotproc/src/hotproc.c - dead code
pmdas/logger/logger.c - safe
pmdas/papi/papi.c - same as linux_proc
pmdas/trace/src/trace.c and pmdas/trace/src/comms.c - has own main loop,
could be fixed easily
pmlogger/... - all done
|