Writing Monitors for the Event Monitoring Service (December 1999)

96 Chapter3
Creating a Resource Monitor
Processing a Monitor Request Event
— RM_QUERY_REQUEST This checks one time only. There is no
unregister associated with it.
Monitor Request Objects
When a Monitor Request Event occurs, rm_get_next_event() creates a
Monitor Reply object that the resource monitor should use to reply to the
request. The following fields of the Monitor Reply object are defined. The
resource monitor should read the RmResourceName (using rm_get) and
set the RmResourceType and RmMonitorReply object fields. Table 3-6
lists the Monitor Reply object fields.
Table 3-6 Monitor Reply Object Fields
Field Name Type Description
RmLifetime
Option
ubit32 Determines how long this monitor
request should last if it is accepted.
Valid values are:
RM_NON_PERSISTENT_REQUEST
The monitor request should exist as
long as the resource monitor exists (or
until a client sends an Unregister
Monitor Request). If the resource
monitor process dies or if the system is
rebooted, the monitor request will
vanish.
RM_PERSISTENT_REQUEST
EMS should store the monitor request
to disk. If the resource monitor process
dies or if the system is rebooted, EMS
should automatically re-register the
request with a new instance of the
resource monitor. The request will only
be removed when a client sends an
Unregister Monitor Request.