CORBA 2.3.3 Programmer's Guide for C++

core makes an upcall to the registered event handler. The types of events that an event handler can register with the core
are:
Time
Tell me when n ticks have elapsed.
Outside of the ORB internals, Fw_Timer events are most often used in their derivative form, NSDEFw_Timer,
which blocks a thread for a specified interval. This usage is described in Using a Timer for a Thread.
Socket I/O
Tell me when a completion occurs on socket n.
The key for socket events is the socket number and the type of socket operation, or affinity (Listen, Connect, Read,
Write, or Exception).
Guardian client I/O
Tell me when a nowait I/O operation I initiated completes.
Nowait FILE_OPEN_, WRITEREAD, SERVERCLASS_SEND_, and similar operations use the file number and
tag as the key that maps a completion to an event.
Guardian server I/O
Tell me when an open message for subdevice x is pulled from $RECEIVE and Tell me when a WRITEREAD
message for session yz (corresponding to a particular OPEN) is pulled from $RECEIVE.
Part of the event core is a component that manages $RECEIVE as a special form of Guardian client I/O. The
$RECEIVE event handler that is part of the event framework opens $RECEIVE and keeps a READUPDATE call
posted against it. When a READUPDATE call completes, the $RECEIVE event handler determines which kind of
message was received, creates an event, and delivers it to the event handler (if any) registered to handle the
message.
Layers of the Event Core
At the center of the event core is the null thread and the data structures it works with. The core parts of the NonStop
CORBA timer, socket, and file-system client components wrap the pthread API with classes that provide an abstraction
of the various events. The TS/MP client event components are derived from file-system client events. The file-system
server event abstraction is built as a user of file-system client events to manage $RECEIVE.
I/O Event-Handler Framework
The I/O event-handler framework is a set of classes that use the event core to provide an abstraction of the work required
to create connections and transfer data between a client and a server. This abstraction is defined in the header file
ehbase.h. The problem space is separated into three session roles and two protocol stack roles.
The session roles are the usual listener, client, and server roles. A listener waits for connect indications at a specific
address. A client connects to the address; the listener creates a server to handle the session; and then the listener waits for
another connection. The client and server exchange an indeterminate number of messages over an indeterminate amount
of time. Then the client and/or server forces a disconnect.
The protocol stack rolesevent handler and event-handler userallow the components of the NonStop CORBA GIOP to
interact with a generic event handler, and the event handlers to interact with a generic user.
A legacy wrapper can operate on either of two levels with respect to the client, server, or listener roles: that of the
event-handler userusing one of the event handlers provided by NonStop CORBAor that of the event handler, if the
NonStop CORBA event handler for that protocol does not provide the necessary semantics. If possible, a legacy wrapper
should act as an event-handler user rather than as an event handler.