Clients that register to receive asynchronous notification of events are inherently event-driven. Event-driven programs are typically built using an event loop, which is executed after program initialization. The event loop never exits, but invokes program callbacks as events occur.
By default, the .NET architecture takes care of the multi-thread asynchronous process of events using thread pools. As long as the client program does not exit, all event callbacks are invoked automatically using a thread in the thread pool.
For those clients that use their own event loop in a single thread environment, the API provides the SPDProcessEvent function. Once the SPDProcessEvent is called, all events are queued. Each time SPDProcessEvent is called, all messages in the queue are taken off and passed to the thread, one at a time, to be processed by the client. SPDProcessEvent calls the client thread to process all the pending events.
Forms of Events
An event can be any of the following:
Receipt of events from the Event Server
An expired timer
Clients specify event callbacks by calling the SPDHandleEvent function (see Section 6.6).
Timers
Clients specify timers with the functions SPDAddTimeOut (see Section 6.2) and SPDRemoveTimeOut (see Section 6.12). There is no limit to the number of timers that can be active at any one time.