pmlookupipc(3) [centos man page]
PMLOOKUPIPC(3) Library Functions Manual PMLOOKUPIPC(3) NAME
__pmAddIPC, __pmLookupIPC, __pmFdLookupIPC, __pmOverrideLastFd, __pmPrintIPC, __pmResetIPC - IPC version infrastructure support C SYNOPSIS
#include <pcp/pmapi.h> #include <pcp/impl.h> int __pmAddIPC(int fd, __pmIPC ipc); int __pmLookupIPC(__pmIPC **ipcp); int __pmFdLookupIPC(int fd, __pmIPC **ipcp); void __pmOverrideLastFd(int fd); void __pmPrintIPC(void); void __pmResetIPC(int fd); cc ... -lpcp DESCRIPTION
IPC channels throughout the distributed PCP framework are affected by the PCP 2.0 (and later) PDU changes. These functions are the inter- face to the libpcp IPC connection management global data. This data consists of a hash table of __pmIPC structures (indexed by file descriptor) and a cached, most-recently-used file descriptor. Newly created IPC channels must be registered with the hash table using __pmAddIPC, such that the PDU sending and decoding routines can determine whether they need to perform any PDU version translations or not, for backward compatibility with previous the PCP 1.x IPC proto- col. __pmLookupIPC and __pmFdLookupIPC both provide handles to the __pmIPC structure associated with the given file descriptor, as previously established by a call to __pmAddIPC. The difference between the two is that one allows an explicit file descriptor lookup, and the other uses the cached, most-recently-used file descriptor. So __pmLookupIPC actually calls __pmFdLookupIPC using this cached file descriptor as the argument. The justification for having both is that in some places it is not possible to use __pmFdLookupIPC (which is preferred), since at that particular level of the PMAPI a file descriptor is not available (see the __pmDecodeError code for an example). The __pmOverrideLastFd is an escape mechanism for use in those situations where the last PDU fetch did not go through the usual channels (ie. __pmGetPDU), so as to ensure that the cached file descriptor is the correct file descriptor for the PDU which is currently being pro- cessed. This will typically be used for archive PDU processing or where version information is not available for a given file descriptor (eg. immediately prior to a PDU version exchange). __pmPrintIPC is a useful debugging routine for displaying a table mapping all currently registered file descriptors to their associated PDU version numbers. Unused entries in this table should display the value zero in the version column. __pmResetIPC resets the version information associated with the given file descriptor to some known (invalid) number. Subsequent lookups on this file descriptor will return an UNKNOWN_VERSION embedded within the __pmIPC structure. SEE ALSO
PMAPI(3) DIAGNOSTICS
A negative return value from __pmLookupIPC indicates that the requested file descriptor is not registered in the hash table. This typi- cally indicates closure of an IPC channel, so PM_ERR_IPC is returned if this is the case. Performance Co-Pilot PCP PMLOOKUPIPC(3)
Check Out this Related Man Page
PMDAMAIN(3) Library Functions Manual PMDAMAIN(3) NAME
pmdaMain, pmdaGetContext, pmdaSetResultCallBack, pmdaSetCheckCallBack, pmdaSetDoneCallBack, pmdaSetEndContextCallBack - generic PDU pro- cessing for a PMDA C SYNOPSIS
#include <pcp/pmapi.h> #include <pcp/impl.h> #include <pcp/pmda.h> cc ... -lpcp_pmda -lpcp void pmdaMain(pmdaInterface *dispatch); void pmdaSetCheckCallBack(pmdaInterface *dispatch, pmdaCheckCallBack callback); void pmdaSetDoneCallBack(pmdaInterface *dispatch, pmdaDoneCallBack callback); void pmdaSetResultCallBack(pmdaInterface *dispatch, pmdaResultCallBack callback); void pmdaSetEndContextCallBack(pmdaInterface *dispatch, pmdaEndContextCallBack callback); int pmdaGetContext(void); DESCRIPTION
For Performance Metric Domain Agents (PMDA(3)) using the binary PDU protocols to communicate with pmcd(1), the routine pmdaMain provides a generic implementation of the PDU-driven main loop. dispatch describes how to process each incoming PDU. It is a vector of function pointers, one per request PDU type, as used in the DSO in- terface for a PMDA, namely: /* * Interface Definitions for PMDA Methods */ typedef struct { int domain; /* set/return performance metrics domain id here */ struct { unsigned int pmda_interface: 8; /* PMDA DSO interface version */ unsigned int pmapi_version : 8; /* PMAPI version */ unsigned int flags : 16; /* optional feature flags */ } comm; /* set/return communication and version info */ int status; /* return initialization status here */ union { struct { /* PMDA_INTERFACE_2 or _3 */ pmdaExt *ext; int (*profile)(__pmProfile *, pmdaExt *); int (*fetch)(int, pmID *, pmResult **, pmdaExt *); int (*desc)(pmID, pmDesc *, pmdaExt *); int (*instance)(pmInDom, int, char *, __pmInResult **, pmdaExt *); int (*text)(int, int, char **, pmdaExt *); int (*store)(pmResult *, pmdaExt *); } two, three; struct { /* PMDA_INTERFACE_4 or _5 */ pmdaExt *ext; int (*profile)(__pmProfile *, pmdaExt *); int (*fetch)(int, pmID *, pmResult **, pmdaExt *); int (*desc)(pmID, pmDesc *, pmdaExt *); int (*instance)(pmInDom, int, char *, __pmInResult **, pmdaExt *); int (*text)(int, int, char **, pmdaExt *); int (*store)(pmResult *, pmdaExt *); int (*pmid)(char *, pmID *, pmdaExt *); int (*name)(pmID, char ***, pmdaExt *); int (*children)(char *, int, char ***, int **, pmdaExt *); } four, five; struct { /* PMDA_INTERFACE_6 */ pmdaExt *ext; int (*profile)(__pmProfile *, pmdaExt *); int (*fetch)(int, pmID *, pmResult **, pmdaExt *); int (*desc)(pmID, pmDesc *, pmdaExt *); int (*instance)(pmInDom, int, char *, __pmInResult **, pmdaExt *); int (*text)(int, int, char **, pmdaExt *); int (*store)(pmResult *, pmdaExt *); int (*pmid)(char *, pmID *, pmdaExt *); int (*name)(pmID, char ***, pmdaExt *); int (*children)(char *, int, char ***, int **, pmdaExt *); int (*attribute)(int, int, const char *, int, pmdaExt *); } six; } version; } pmdaInterface; This structure has been extended to incorporate the multiple interface versions that have evolved over time. For pmdaMain, dispatch->do- main and dispatch->status are ignored. The comm.pmda_interface field is used to determine the interface used by the PMDA. Setting this field to PMDA_INTERFACE_2 or PMDA_INTERFACE_3 will force pmdaMain to use the callbacks in the version.two or version.three structure. A setting of PMDA_INTERFACE_4 or PMDA_INTERFACE_5 will force pmdaMain to use the callbacks in the version.four or version.five structure, and similarly a PMDA_INTERFACE_6 setting forces pmdaMain to use the callbacks in the version.six structure. Any other value will result in an error and termination of pmdaMain. Note that the use of dispatch as the interface between the pmcd(1) and the methods of the PMDA allows each PMDA to be implemented as though it were a DSO, with pmdaMain providing a convenient wrapper that may be used to convert from the DSO interface to the binary PDU (daemon PMDA) interface. pmdaMain executes as a continuous loop, returning only when an end of file is encountered on the PDU input file descriptor. CALLBACKS
In addition to the individual PDU processing callbacks - pmdaProfile(3), pmdaFetch(3), pmdaDesc(3), pmdaInstance(3), pmdaText(3), pmdaS- tore(3), pmdaPMID(3), pmdaName(3), pmdaChildren(3), and pmdaAttribute(3) there are other callbacks that can affect or inform all PDU pro- cessing within a PMDA, namely check, done and end. These callbacks should be set with pmdaSetCheckCallBack, pmdaSetDoneCallBack and pm- daSetEndContextCallBack. If not null, check is called after each PDU is received (but before it was processed), and done is called after each PDU is sent. If check returns a value less than zero (typically PM_ERR_AGAIN), the PDU processing is skipped and in most cases the function value is returned as an error PDU to pmcd(1) - this may be used for PMDAs that require some sort of deferred connection or reconnect protocols for the underly- ing sources of performance metrics, e.g. a DBMS. The error indication from check is not passed back to pmcd(1) in the cases where no ac- knowledgment is expected, e.g. for a PDU_PROFILE. The end callback allows a PMDA to keep track of state for individual clients that are requesting it to perform actions (PDU processing). Using pmdaGetContext a PMDA can determine, at any point, an integer identifier that uniquely identifies the client tools at the remote end of PMCD (for local context modes, this identifier is always zero). This becomes very important for handling event metrics, where each event must be propogated once only to each interested client. It also underlies the mechanism whereby connection information is passed to the PMDA, such as the the credentials (user and group identifiers) for the client tool. One final callback mechanism is provided for handling the pmResult built for a PDU_RESULT in response to a PDU_FETCH request. By default, pmdaMain will free the pmResult once the result has been sent to the pmcd(1). For some PMDAs this is inappropriate, e.g. the pmResult is statically allocated, or contains a hybrid of pinned PDU buffer information and dynamically allocated information. pmdaSetResultCallback may be used to define an alternative callback from pmdaMain. DIAGNOSTICS
These messages may be appended to the PMDA's log file: PMDA interface version interface not supported The interface version is not supported by pmdaMain. Unrecognized pdu type The PMDA received a PDU from pmcd that it does not recognize. This may indicate that the pmcd process is using a more advanced interface than pmdaMain. If the PMAPI(3) debug control variable (pmdebug) has the DBG_TRACE_LIBPMDA flag set then each PDU that is received is reported in the PM- DA's log file. SEE ALSO
pmcd(1), PMAPI(3), PMDA(3), pmdaProfile(3), pmdaFetch(3), pmdaDesc(3), pmdaInstance(3), pmdaText(3), pmdaStore(3), pmdaPMID(3), pm- daName(3), pmdaChildren(3), and pmdaAttribute(3). Performance Co-Pilot PCP PMDAMAIN(3)