Processes the specified interrupt set.
#include <nks/thread.h>
NXBool_t NXProcessInterruptSet (
NXInterruptSet_t *set,
NXInterruptId_t id,
NXInterruptId_t *processed_id);
(IN) Points to the set that needs to be processed.
(IN) Specifies the interrupt ID to process. You can set this to 0 to determine if any interrupts are currently pending.
(OUT) Points to the location that returns the interrupt that was processed.
Returns one of the following:
NXProcessInterruptSet checks if the specified interrupt is pending in the specified set. If the specified interrupt is pending, NXProcessInterruptSet returns TRUE, processes the interrupt, and clears the specified interrupt from the set.
If id is set to zero, NXProcessInterruptSet processes the first pending interrupt by scanning the specified set from right to left. When NXProcessInterruptSet returns, the location pointed to by processed_id (if non-NULL) is set to the ID of the processed interrupt.
Multithreaded applications usually need a mechanism for inter-thread communication within a virtual machine. NKS provides an inter thread communication mechanism by means of an “interrupt” to a thread. In simple terms, a thread wanting to communicate with another thread can post an interrupt to the target thread using the NXThreadInterrupt function. The target thread can then poll for posted interrupts using NXThreadIsInterrupted, and optionally retrieve an “interrupt set” consisting of a snapshot of all the interrupts posted to the thread. The thread can then determine what interrupts have been posted using NXProcessInterruptSet.
A set of 64 interrupts is available per thread, and is defined by the data types NX_INTR1 through and including NX_INTR64. Interrupts are always scanned from NX_INTR1 to NX_INTR64. NKS does not define any relative order of importance among interrupts. An application is free to prioritize interrupts in its own way.
NOTE:NX_INTR1 should not be used because of a header error that defines its value as 0, which is the same value that you pass to scan all interrupts.
NKS also does not impose any semantics with an interrupt. An application is free to define its own semantics for each of the individual interrupts. Thus, the thread interrupt mechanism really serves as an inter thread notification mechanism. Posting an interrupt to a thread does not cause it to asynchronously execute an “interrupt handler.” Instead, the “interrupt handler” is really voluntarily executed by the “interrupted thread” at its own convenience. The thread can then determine suitable course of action for each pending interrupt based on the semantics associated by the application with each interrupt. For example, a particular interrupt may be used by the application to indicate that a thread has to exit. Thus, instead of asynchronously destroying a thread, and thereby ending up with a possibly inconsistent state due to resources not being cleaned up by the thread destroyed in such a fashion, a thread can be requested to exit on its own by posting it the application defined “thread exit” interrupt.
The set parameter contains an interrupt set snapshot obtained using the NXThreadIsInterrupted function. Once the snapshot is taken, the snapshot is not updated automatically to reflect any new interrupts that might have been posted to the thread.
An individual interrupt cannot be “stacked.” That is, once a specific interrupt has been posted, it is indistinguishable from subsequent interrupts of the same ID that may get posted before interrupts are sampled. Putting it another way, when a pending interrupt is found, there is no way in the thread interrupt mechanism to find out how many times that particular interrupt was posted.
NXProcessInterruptSet (in conjunction with NXThreadIsInterrupted) provides the framework for structuring application-specific handling of inter-thread interrupts.