HP-UX Event ManagerProgrammer's Guide

outside the callback function, after you have finished using the event; otherwise, you may
encounter memory leak.
For information about assigning an event, see “Reassigning and Replicating EVM Events”
(page 32).
Choosing a Connection Policy
If your program is a posting client, you must choose a policy for connecting to the EVM daemon.
You can choose one of the following options:
• Create a connection when the program starts, and maintain it until the program terminates
(permanent connection).
• Create a connection each time that you need to post an event, and destroy it immediately
afterwards (transient connection).
The cost in processing time of creating an EVM connection is significant, because the setup and
authentication protocol require several message transactions as well as some file I/O. As a general
rule, you must maintain a permanent connection if you want to post events frequently during
normal program operation. If you choose this option, your code must handle unexpected
disconnection if the EVM daemon is terminated. For information about handling disconnection,
see “Handling Disconnections” (page 34).
If you expect to post events infrequently — for example, only if unexpected errors occur —
consider using a transient connection. Although a transient connection is more expensive in
set-up time if multiple events are posted, it eliminates both the system resource cost of a permanent
connection and the need for your code to deal with an unexpected disconnection. The simplest
way to post events to the local daemon with a transient connection is to pass NULL as the
connection argument to EvmEventPost or EvmEventPostVa.
If you do not require a permanent connection, but you expect to post several events over a short
period under some circumstances; consider creating a temporary connection that you will destroy
when the activity is completed, rather than posting successive events using a separate connection
for each.
Subscribing clients must maintain permanent connections to be assured of receiving events.
Handling Disconnections
If your program is a subscribing client, it is important that you handle EVM daemon
disconnection correctly. EVM daemon disconnection must not occur under normal operation,
but may occur in a system that is being tested or if a fault is encountered. If the EVM daemon
terminates, it is usually restarted automatically within few seconds by the Essential Services
Monitor daemon. For more information, see esmd(1M).
Although you must always test the return code from functions dealing with a connection, it is
especially important to do so for a subscribing client. This is because a subscribing client may
spend most of its time waiting for activity that depends on a proper connection.
If disconnected, your program drops out of its select or EvmConnWait call, and subsequent
calls to EvmConnCheck and EvmConnDispatch returns failure status codes. If this happens,
the program must not return immediately to the select or EvmConnWait call, because that
results in a CPU-bound loop. Instead, determine whether the status code indicates a connection
error and, if so, destroy the connection using EvmConnDestroy and then attempt to reconnect.
If the initial attempt to reconnect fails, continue to retry the connection periodically until it is
re-established. The recommended retry interval is once per second for the first 60 seconds, and
every five seconds thereafter, until the connection is restored, because the daemon usually restarts
automatically following any failure.
34 The EVM Programming Interface