Waiting on events

Monitoring specifications are written to the monitor file.

Once monitoring specifications are successfully written to the monitor file, the consumer process will block for an event occurrence using select() or read(). Consumers are only notified of events that occur once they block in select() or read(). There are three ways that the process can return from select() or a blocking read():

1. The event has occurred the specified number of times.
   • Non-error case. Consumer should read event data to determine how to handle the event.
2. There was a problem when setting up the event inside the AIX® Event Infrastructure kernel extension.
   Errors may occur before the event is registered for monitoring with the event producer:

   • read()
     • If there is another thread waiting in read, the read will fail with EBUSY
     • If there was no write done before this read, the read will just return 0, with 0 bytes read.
   • select()
     Note:

     Due to the implementation of the select system call, in order for select() to return an error, the underlying file system operations must return EBADF. As a result, if any of the following conditions are met, select() will return EBADF.

     • Another thread is attempting a select
     • The monitor file has been deleted
     • There was no write done specifying monitoring specifications
     • There was an error when registering with the IOS subsystem

     In these cases, there will be no event data to read.

3. There was a problem setting up the event with the event producer.

   If an attempt is made to register the event with the event producer, an entry will be logged into the buffer for the consumer to read. To determine what error occurred, the RC_FROM_EVPROD returned in the event data should be referenced in the event producer's documentation. Note that the event output for this case will only contain the timestamp, sequence number and return code from the event producer, regardless of what INFO_LVL has been specified. See Reading Event Data for an example.

   In this case, select() will return EBADF, but read() will return the return code from the underlying uio_move operation.

If the consumer process has specified a NOTIFY_CNT greater than 1, information about each event occurrence will be logged in the consumer's buffer until the number of events request have occurred. The consumer process will only be woken up if the event has occurred the requested number of times, or an unavailable event has occurred. Once the consumer process is woken up, it will no longer be monitoring the event until it re-issues a select() or blocking read() call for the monitor file.

If a consumer has specified a NOTIFY_CNT of -1, the consumer process will be woken up after each occurrence of the event, and any event which occurs after the initial successful select() or blocking read() will be logged in the consumer buffer.

The select() and read() calls will not block if there is unread event data in the buffer.