The event broker is a task that constantly monitors activity on attached interactive devices. Currently, interactive devices are attached only to the control port on the 3DO system. The event broker monitors the control port to see what the devices are doing.
Activities on interactive devices are called events. Events include joypad presses and releases, key strokes, mouse rolling, plugging a new control device into the control port, unplugging a device from the control port, and many others. Events can occur on any hardware device attached to the control port. A hardware device is called a pod. The event broker always identifies the pod in which an event occurs.
The event broker starts when the system starts up, and stands between user tasks and the interactive pods on the control port. To work with interactive devices, a user task connects to the event broker and registers itself as a listener. A listener is a task that connects to the event broker to receive event notification and to pass data to pods. To become a listener, a task creates a message port for communication with the event broker. Then the task communicates its requests to the event broker with messages; the event broker responds to these messages with its own messages. I/O operations through the event broker are carried out through messages instead of IOReqs.
In each video field the event broker checks pods for events, 60 times per second on NTSC systems, and 50 times per second on PAL systems. If any of the events it senses match an event in a listener task trigger mask, the event broker composes an event message to send to the listener. That event message contains a pointer to an accompanying data block that contains information about all event types that are specified in either the trigger mask or the capture mask.
The event broker takes a "snapshot" of the pods' states whenever a triggering event occurs. For example, a listener can specify "controller pad button down" as a trigger event and then specify "gunlike-device button pressed" and "keyboard key pressed" as capture events. Whenever a controller pad button is pressed down in a pod, the event broker is triggered to send an event message to the listener. The event message's data block contains the status of "controller pad button down" (true because it was the triggering event), the status of "gunlike-device button pressed" (true or false, depending on whether or not the button was pressed on any attached gunlike devices during the field), and the status of "keyboard key pressed" (true or false, depending on whether or not any keys were pressed on any attached keyboards). The listener task now knows that the controller pad button was pressed, and knows whether or not any keyboard keys or buttons on gunlike devices were pressed during the same video field. The listener can then take appropriate action.
Because the event broker notifies listeners of events via messages, a listener task can enter the wait state for an event broker message, just as a task waits for any other message. This allows synchronous I/O with interactive pods. A listener can also continue execution after sending an event broker message, which allows asynchronous I/O. In either case, whenever a listener task receives a message from the event broker, it must reply to the event broker and say the message is processed and can be reused. If the listener task does not reply, the event message queue can fill up, and it can lose events in which it was interested.
The event broker sends events to the appropriate focus holder-if connected tasks are set up to pay attention to focus. Whenever a task connects to the event broker, it can request to be one of three listener types: