1PMWEBTIMERREGISTER(3) Library Functions Manual PMWEBTIMERREGISTER(3)
2
6 pmWebTimerRegister, pmWebTimerRelease, pmWebTimerSetMetricRegistry -
7 thread-safe timer list management
8
10 #include <pcp/pmwebapi.h>
11 typedef void (*pmWebTimerCallBack)(void *data);
13 int pmWebTimerRegister(pmWebTimerCallBack callback, void *data);
14 int pmWebTimerRelease(int seq);
16 int pmWebTimerSetMetricRegistry(struct mmv_registry *registry);
17 cc ... -lpcp_web
18
20 The pmWebTimerRegister and related API functions provide a convenient
21 thread-safe API for applications to manage a list of timer driven call‐
22 backs. On the first call to pmWebTimerRegister or pmWebTimerSetMetri‐
23 cRegistry, an internal timer is set up and initialized to fire every
24 1.0 seconds. Each time the timer fires, all currently registered call‐
25 back functions will be called serially with the opaque data pointer
26 that was supplied when each function was registered. The pmWebTimer‐
27 CallBack typedef provides a suitable callback function prototype.
28 All registered callback functions should be non-blocking and execute
30 quickly and synchronously. Typical callback functions include refresh‐
31 ing instrumentation, calculating and updating performance metric val‐
32 ues, periodic garbage collection and any other local function that re‐
33 quires regular execution.
34 The pmWebTimerSetMetricRegistry function provides a convenient way for
36 an application to pass in a pointer to an libpcp_mmv(3) registry that
37 has been suitably initialized by the calling application. This reg‐
38 istry will be used to dynamically create six server resource metrics
39 named NAME.mem.datasz, NAME.mem.maxrss, NAME.cpu.total, NAME.cpu.sys,
40 NAME.cpu.user and NAME.pid, where NAME is the root PCP PMNS(5) name set
41 up by the calling application. These metrics should be reasonably self
42 explanatory; they provide resource usage metrics from the calling ap‐
43 plication / server and use getrusage(2), times(2) and getpid(2).
44
46 The pmWebTimerRegister function returns a positive integer handle that
47 may be subsequently used in a call to pmWebTimerRelease to remove a
48 timer from the internal timer list. When a timer is removed with a
49 call to pmWebTimerRelease, the internal data structures are freed. The
50 caller however, is responsible for freeing the associated data (since
51 it may or may not be dynamically allocated).
52
54 On failure a negative PMAPI error code is returned in all cases.
55
57 pmproxy(1), mmv_stats_registry(3), PMAPI(3) and PMWEBAPI(3).
58Performance Co-Pilot PCP PMWEBTIMERREGISTER(3)