Handles can have operations invoked on them syn-
chronously without blocking the application process.
Initiation Dispatcher
Defines an interface for registering, removing, and
dispatching Event Handlers. Ultimately, the
Synchronous Event Demultiplexer is respon-
sible for waiting until new events occur. When
it detects new events, it informs the Initiation
Dispatcher to call back application-specific event
handlers. Common events include connection accep-
tance events, data input and output events, and timeout
events.
Event Handler
Specifies an interface consisting of a hook method [3]
that abstractly represents the dispatching operation for
service-specific events. This method must be imple-
mented by application-specific services.
Concrete Event Handler
Implements the hook method, as well as the meth-
ods to process these events in an application-specific
manner. Applications register Concrete Event
Handlers with the Initiation Dispatcher to
process certain types of events. When these events ar-
rive, the Initiation Dispatcher calls back the
hook method of the appropriate Concrete Event
Handler.
There are two Concrete Event Handlersinthe
logging server: Logging Handler and Logging
Acceptor.TheLogging Handler is responsi-
ble for receiving and processing logging records. The
Logging Acceptor creates and connects Logging
Handlers that process subsequent logging records
from clients.
The structure of the participants of the Reactor pattern is
illustrated in the following OMT class diagram:
Initiation DispatcherInitiation Dispatcher
handle_events()
register_handler(h)
remove_handler(h)
select (handlers);
foreach h in handlers loop
h.handle_event(type)
end loop
Event HandlerEvent Handler
handle_event(type)
get_handle()
handlers
HandleHandle
owns
uses
notifies
ConcreteConcrete
EventEvent
HandlerHandler
Synchronous EventSynchronous Event
DemultiplexerDemultiplexer
select()
1
N
8 Dynamics
8.1 General Collaborations
The following collaborations occur in the Reactor pattern:
When an application registers a Concrete Event
Handler with the Initiation Dispatcher the
application indicates the type of event(s) this Event
Handler wants the Initiation Dispatcher to
notify it about when the event(s) occur on the associated
Handle.
The Initiation Dispatcher requests each
Event Handler to pass back its internal Handle.
This Handle identifies the Event Handler to the
OS.
After all Event Handlers are registered, an applica-
tion calls handle events to start the Initiation
Dispatcher’s event loop. At this point, the
Initiation Dispatcher combines the Handle
from each registered Event Handler and uses the
Synchronous Event Demultiplexer to wait
foreventstooccurontheseHandles.Forin-
stance, the TCP protocol layer uses the select syn-
chronous event demultiplexing operation to wait for
client logging record events to arrive on connected
socket Handles.
The Synchronous Event Demultiplexer no-
tifies the Initiation Dispatcher when a
Handle corresponding to an event source becomes
“ready,” e.g., that a TCP socket is “ready for reading.”
The Initiation Dispatcher triggers Event
Handler hook method in response to events on
the ready Handles. When events occur, the
Initiation Dispatcher uses the Handles ac-
tivated by the event sources as “keys” to locate and
dispatch the appropriate Event Handler’s hook
method.
The Initiation Dispatcher calls back to
the handle event hook method of the Event
Handler to perform application-specific functionality
in response to an event. The type of event that occurred
can be passed as a parameter to the method and used
internally by this method to perform additional service-
specific demultiplexing and dispatching. An alternative
dispatching approach is described in Section 9.4.
The following interaction diagram illustrates the collabo-
ration between application code and participants in the Re-
actor pattern:
3