Showing changes from revision #2 to #3: Added | Removed | Changed

Programmer's Reference Manuals

» Program Environment

Execution contexts

There are several different execution contexts which code can find itself running in. These execution contexts can place limits on what actions the code can perform – for example, interacting with the filing system from within an interrupt handler is forbidden. Although developers of simple applications may not need to know the details of the different execution contexts, if you are developing modules or using RISC OS-specific features such as callbacks then knowledge of at least some of the different contexts is necessary.

At the basic level, there are two types of execution context: foreground and background. Applications are described as running in the foreground, and they have few restrictions on what operations they can perform (e.g. they can interact with the filing system, and there are no limits on execution time). Meanwhile, the background is mainly the domain of interrupt handlers and abort handlers, and there are several different types of restriction which can be in place.

Viewed from the least restrictive (foreground) to the most restrictive (background), the following execution contexts exist in the system:

1. The foreground
   1. Application context (user-mode code)
   2. CallBack handlers
   3. Transient callbacks
   4. SWIs issued from the foreground, *Commands, and most other supervisor-mode code
2. The background
   1. RTSupport threads
   2. Interrupt handlers (including e.g. OS_CallAfter / OS_CallEvery handlers)
   3. Abort handlers
   4. FIQ handlers

This nesting also represents the way in which the different contexts can interrupt each other; e.g. an application running in the application context can be interrupted by a transient callback or an RTSupport thread. However the execution of an interrupt handler cannot be interrupted by either of these; the interrupt handler must run to completion and the system must return one or more steps towards the foreground.

Of course there are some exceptions, e.g. if a FIQ handler crashes then the CPU will invoke the abort handler. And some foreground SWIs (e.g. OS_ReadC ) may elect to trigger transient callbacks, bypassing the usual “Is “are the we supervisor returning stack to empty?” user mode?” check that the kernel performs.