BOOST WIKI | Multiplexing | RecentChanges | Preferences | Page List | Links List
No diff available--this is the first major revision.
The following is a glossary of frequently used expressions in the Boost discussion about demultiplexing. The goal of this document is to make it possible for everyone to follow threads on the boost mailinglist about this subject. If you want to participate in the discussions than it is highly recommended to read the literature listed at the end of this document, as well.
- A service request for a resource managed by an OS.
- Identify resources that are managed by an OS. These resources commonly include network connections, open files, timers, synchronization objects, etc. While a Handle is associated with a single resource, it can receive multiple Events specific to the Handle type.
- Event Handler
- An object that handles the event requests for a given resource type. Each event type for the associated resource is handled by different member functions.
- Many inputs one output. Also known as: Encoder (electronics).
- One input many outputs. An Event Demultiplexor is an object that dispatches Events from a limited number of sources (Handles) to their respective handlers. Also known as: Decoder (electronics).
- One by one. A Synchronous Event Demultiplexor runs in a single thread, making the Events available to the application synchronously, as part of its normal execution path. Also known as: Blocking. A Synchronous call blocks, waiting for an event to occur.
- Not Synchronous. Events are dispatched to a pool of threads, causing them to be processed in parallel. Also known as: Overlapped (windows).
- Overlapped IO
- Asynchronous IO (windows). See Asynchronous.
- Initiation Dispatcher
- Defines an interface for registering, removing, and dispatching Event Handlers 
- At the core of the Reactor architectural pattern is a Synchronous Event Demultiplexor that blocks awaiting events to occur on a set of Handles. The Synchronous Event Demultiplexor returns when it is possible to initiate an operation on a Handle without blocking. It then notifies the Initiation Dispatcher, which synchronously calls back to the Event Handler associated with the event. 
- Asynchronous Operation
- Asynchronous Operations are run to completion by the Asynchronous Operation Processor. This component is typically implemented by the OS (IO completion ports (windows NT), Asynchronous Procedure Calls (APC) (windows NT), AIO Family of Asynchronous I/O Operations (UNIX)). 
- Completion Handler
- The Proactor pattern uses Completion Handler interfaces that are implemented by the application for Asynchronous Operation completion notification. 
- Completion Dispatcher
- The Completion Dispatcher is responsible for calling back to the applications Completion Handlers when Asynchronous Operations complete. When the Asynchronous Operation Processor completes an asynchronously initiated operation, the Completion Dispatcher performs an application callback on its behalf. 
- Proactive Initiator
- Any entity in an application that initiates an Asynchronous Operation. The Proactive Initiator registers a Completion Handler and a Completion Dispatcher with a Asynchronous Operation Processor, which notifies it when the operation completes. 
- The Proactor architectural pattern allows event-driven applications to efficiently demultiplex and dispatch service requests triggered by the completion of asynchronous operations, to achieve the performance benefits of concurrency without incurring certain of its liabilities. 
 [Reactor, An Object Behavioral Pattern for Demultiplexing and Dispatching Handles for Synchronus Events - Douglas C. Schmidt]
 [Proactor, An Object Behavioral Pattern for Demultiplexing and Dispatching Handles for Asynchronous Events - Irfan Pyarali, Tim Harrison, Thomas D. Jordan and Douglas C. Schmidt]
Disclaimer: This site not officially maintained by Boost Developers