The QMF2 API has a work-queue Callback approach. All asynchronous events are represented by a WorkItem object. When a QMF event occurs it is translated into a WorkItem object and placed in a FIFO queue. It is left to the application to drain this queue as needed.
This new API does require the application to provide a single callback. The callback is used to notify the application that WorkItem object(s) are pending on the work queue. This callback is invoked by QMF when one or more new WorkItem objects are added to the queue. To avoid any potential threading issues, the application is not allowed to call any QMF API from within the context of the callback. The purpose of the callback is to notify the application to schedule itself to drain the work queue at the next available opportunity.
For example, a console application may be designed using a select() loop. The application waits in the select() for any of a number of different descriptors to become ready. In this case, the callback could be written to simply make one of the descriptors ready, and then return. This would cause the application to exit the wait state, and start processing pending events.
The callback is represented by the Notifier virtual base class. This base class contains a single method. An application derives a custom notification handler from this class, and makes it available to the Console or Agent object.
The following diagram illustrates the Notifier and WorkQueue QMF2 API Event model.
Notes
- There is an alternative (simpler but not officially QMF2) API based on implementing the QmfEventListener.
- BlockingNotifier is not part of QMF2 either but is how most people would probably write a Notifier.
- It's generally not necessary to use a Notifier as the Console provides a blocking getNextWorkitem() method.
@author Fraser Adams