Other senders, such as a file server, might require that notifications be delivered asynchronously so that they are not blocked for long periods of time, waiting for receivers to complete notification handling.
The Notification framework provides two implementations of MNotifier that you can use depending on your needs. TNotifier provides a synchronous implementation and TAsynchronousNotifier provides one that is asynchronous.
When you call TNotifier::Notify, the notifier calls the Notify member function of all the connections interested in that notification in the same thread in which TNotifier::Notify was called. When the call completes, the sender is assured that all receivers interested in the notification have received it. When they receive the notification, receivers also know that it reflects the current state of the sender as long as it has not somehow changed since then.
However, this means that a receiver can tie up the sender by taking a long time to process the notification.
When you call TAsynchronousNotifier::Notify, a request to perform the notification is passed to a request processor. See "Notifier classes" on page 46 for more information on request processors. The sender can then immediately continue to perform other work. When the request processor eventually delivers the notification, receivers can not make any assumptions about the state of the sender (even that it still exists).
Even with an asynchronous notifier, impolite receivers can delay other receivers from receiving a notification. Through specialization of TNotifierConnection, you can create new classes of connection that deliver notifications asynchronously (the Notification framework does not provide such a class). You can create connections that deliver notifications using IPC or monitors and conditions. See OS Services for more information.
[Contents]
[Previous]
[Next]
Click the icon to mail questions or corrections about this material to Taligent personnel.