So far, everything we’ve done assumes that events are being generated synchronously. We’ve also assumed that this wouldn’t create a problem for the object that generates the events. Remember that events are fired on the caller’s thread. In some cases, this thread may have other work to do. If we write event-handler methods that do a great deal of work before returning to the caller, we may hold up the caller’s thread longer than is safe. Holding up the caller’s thread could also be a problem if it is important that all event listeners be notified quickly. Since the delivery order of events is generally undefined, it would be unfair (or worse) to hold up the delivery of an event to one listener because another is slow to respond.
We could assume that if an event generator didn’t want to be interrupted for long periods of time, it would be implemented to protect itself from this possibility. But another approach is to use an event adapter that queues events and forwards them to the target object on another thread. This type of asynchronous delivery allows the thread that originally fired the event to continue doing whatever it wants, because the method call it made when firing the event returns almost immediately.
Let’s create an example to illustrate how to build this type of
adapter. We have a worker object that runs a thread every 200
milliseconds in order to update a counter. This object will be called
Poller. On every third update it generates a
PollEvent to ...