Handling interrupts

Resource managers that manage an actual hardware resource will likely need to handle interrupts generated by the hardware. For a detailed discussion on strategies for handling interrupts, see the chapter on Handling Hardware Interrupts in the QNX OS Programmer's Guide.

There are two main strategies a resource manager might use for handling hardware interrupts. The resource manager can either inform a resource manager thread via a pulse (discussed in the Handling private messages and pulses section of the Handling Other Messages chapter), or use a dedicated interrupt handling thread with the SIGEV_INTR notification type or an InterruptAttachThread() call. Let's look at the SIGEV_INTR case in more detail.

When the resource manager starts up, it transfers control to thread_pool_start(). This function may or may not return, depending on the flags passed to thread_pool_create() (if you don't pass any flags, the function returns after the thread pool is created). This means that if you're going to handle interrupts, you should set up your interrupt handling before starting the thread pool, or use one of the strategies we discussed above (such as starting a thread for your entire resource manager).

However, if you're going to use the SIGEV_INTR event notification type, there's a catch: the thread that attaches the interrupt (via InterruptAttachThread() or InterruptAttachEvent()) must be the same thread that calls InterruptWait().