Some peripheral devices can cause or signal interrupts on the bus of a Windows CE–based platform. Typically, the peripherals are PC Cards. Some Windows CE–based platforms use standard buses, such as the Peripheral Component Interconnect (PCI) local bus, in which case, expansion cards plugged into the bus can also signal interrupts. Because these peripheral devices can cause or signal interrupts, their stream interface drivers need code to process interrupts.
The recommended method for processing interrupts is for the stream interface driver to spawn a new thread called an interrupt service thread (IST) during its processing of the XXX_Init call. When an interrupt occurs, Windows CE signals the IST. The IST interacts with the peripheral device to perform whatever device-specific processing is necessary to handle the interrupt. This method is beneficial because Windows CE versions 2.12 and earlier do not support nested interrupts. Thus, while an interrupt service routine (ISR) is running, other interrupts are masked for a short time. ISRs should therefore do as little processing as possible, only report the logical interrupt value to the operating system so that Windows CE can activate the corresponding IST. By separating the interrupt processing into a very short ISR and a longer user mode IST, interrupts can be masked for as little time as possible.
ISTs generally run at a high priority so that they can respond quickly to interrupt events. For most drivers, this thread should register to receive interrupt notifications from the InterruptInitialize function. For PC Card drivers, however, the thread receives notifications from the CardRequestIRQ function. PC Card drivers do not process interrupts directly because the built-in PC Card socket driver gets the raw interrupts generated by the PC Card socket. CardRequestIRQ allows you to specify a callback function that the PC Card socket driver calls when an interrupt occurs.