Global Call API for HMP on Windows Programming Guide — August 2006 31
Programming Models
Individual handlers can be written to handle events for each channel. The SRL handler thread can
be used when porting applications developed for other operating systems.
2.2.3 Asynchronous with Windows Callback Model
The asynchronous with Windows callback model allows an asynchronous application to receive
SRL event notification through the standard Windows message handling scheme. This model is
used to achieve the tightest possible integration with the Windows messaging scheme. Using this
model, the entire Intel Dialogic portion of the application could be run on a single thread. This
model calls the sr_NotifyEvt( ) function once to define a user-specified application window handle
and a user-specified message type. When an event is detected, a message is sent to the application
window. The application responds by calling the sr_waitevt() function with a 0 timeout val ue. For
Global Call events and optionally for non-Global Call events, the application must then call the
gc_GetMetaEvent( ) function before servicing the event.
In this model, the SRL event handler thread must be initiated by the application by setting the
SR_MODELTYPE value to SR_STASYNC. For detailed information on this programming model,
see the Standard Runtime Library API Programming Guide.
2.2.4 Asynchronous with Win32 Synchronization Model
The asynchronous with Win32 synchronization model allows an asynchronous application to
receive SRL event notification through standard Windows synchronization mechanisms. This
model uses one thread to run all Intel Dialogic devices and thus requires a lower level of system
resources than the synchronous model. This model allows for greater scalability in growing
systems. For detailed information on this programming model, see the Standard Runtime Library
API Programming Guide.
2.2.5 Extended Asynchronous Programming Model
The extended asynchronous programming model is basically the same as the asynchronous model
except that the application uses multiple asynchronous threads, each of which controls multiple
devices. In this model, each thread has its own specific state machine for the devices that it
controls. Thus, a single thread can look for separate events for more than one group of channels.
This model may be useful, for example, when you have one group of devices that provides fax
services and another group that provides interactive voice response (IVR) services, while both
groups share the same process space and database resources. The extended asynchronous model
can be used when an application needs to wait for events from more than one group of devices and
requires a state machine.
Because the extended asynchronous model uses only a few threads for all Intel Dialogic devices, it
requires a lower level of system resources than the synchronous model. This model also enables
using only a few threads to run the entire Intel Dialogic portion of the application.