PMDAEVENTCLIENT(3)

πŸ“¦
version 7.2.2 Β· 3 versions
, in arch rolling, centos-stream 10, fedora 43, fedora 44

πŸ’– PMDAEVENTCLIENT πŸ’–

okay bestie, welcome to PMDAEVENTCLIENT(3) β€” the part of the Performance Co-Pilot library manual that's literally all about client context tracking interfaces for event queues. yes, we're doing event queues today. put your hair up, hydrate, let's go 🫢


✨ C SYNOPSIS ✨

#include <pcp/pmapi.h>
#include <pcp/pmda.h>

int pmdaEventNewClient(int context);
int pmdaEventEndClient(int context);
int pmdaEventClients(pmAtomValue *avp);

cc ... -lpcp_pmda -lpcp

three little functions. three. and they carry the whole "who's still listening to me" situation on their backs. iconic honestly. πŸ’…


🌸 DESCRIPTION 🌸

so. picture this. a Performance Metrics Domain Agent (a PMDA, if we're being casual) that exports event records. it needs to know which clients are connected to it, because that's the only way it can track which events have already been sent to which clients so far. no cap.

and here's the part that actually matters: only once an event has been sent to every single monitoring tool that registered an interest can that event be discarded and its memory reclaimed. the event has to be seen by everybody before it can leave the group chat. it's giving ✨closure✨.

the PMDA(3) library gives PMDA developers callback routines so they can provide custom handling of client connections and disconnections. cute, right? but here's the fine print bestie β€” if your PMDA is making use of the event queuing mechanism that pmdaEventNewQueue(3) and friends hand you, then client connections and disconnections must be tracked via calls to pmdaEventNewClient and pmdaEventEndClient respectively. not "should". must. periodt.

why? because that's how the library keeps track of when events can be discarded from a queue β€” for example, for the context you specified. and that context parameter?

  • it gets passed into the e_endCallBack function directly, straight up, no middleman
  • for the other callback functions, it's available via the e_context field of the pmdaExt structure
  • and you can also query it at any time using pmdaGetContext(3) πŸŽ€

sometimes a PMDA wants to be extra and export a metric showing the current count of attached clients. honestly? valid. that's what the pmdaEventClients routine is for β€” it fills in the avp pmAtomValue structure on behalf of a PMDA fetch callback routine. it does the paperwork so your fetch callback doesn't have to. slay. πŸ’œ


πŸ”₯ SEE ALSO πŸ”₯

go read those too bestie, i'm not gatekeeping anything 🌈


this page came to you courtesy of Performance Co-Pilot (that's PCP πŸ’–) and it lives under PMDAEVENTCLIENT(3). now go track those clients. your queue believes in you. mwah πŸ§šπŸ’…

πŸ“¦ where this page comes from