C.3.2 The Package Interrupts
The following language-defined
Interrupt_Id is implementation-defined
access protected procedure
Is_Reserved (Interrupt : Interrupt_Id)
Is_Attached (Interrupt : Interrupt_Id)
Current_Handler (Interrupt : Interrupt_Id)
(New_Handler : in
Interrupt : in
(Old_Handler : out
New_Handler : in
Interrupt : in
(Interrupt : in
Reference (Interrupt : Interrupt_Id)
function Get_CPU (Interrupt : Interrupt_Id)
... -- not specified by the language
. . .
The Interrupt_Id type is an implementation-defined
discrete type used to identify interrupts.
The Is_Reserved function returns True if and only
if the specified interrupt is reserved.
The Is_Attached function returns True if and only
if a user-specified interrupt handler is attached to the interrupt.
The Current_Handler function returns a value that represents the attached
handler of the interrupt. If no user-defined handler is attached to the
interrupt, Current_Handler returns null a
value that designates the default treatment; calling Attach_Handler or
Exchange_Handler with this value restores the default treatment
The Attach_Handler procedure attaches the specified handler to the interrupt,
overriding any existing treatment (including a user handler) in effect
for that interrupt. If New_Handler is null
, the default treatment
If New_Handler designates a protected
procedure for to
which the aspect pragma
Interrupt_Handler is False does
, Program_Error is raised. In this case, the operation
does not modify the existing interrupt treatment.
The Exchange_Handler procedure operates in the same manner as Attach_Handler
with the addition that the value returned in Old_Handler designates the
previous treatment for the specified interrupt. If the previous treatment is not a user-defined handler, null
Ramification: Calling Attach_Handler
or Exchange_Handler with this value for New_Handler restores the previous
If the application uses only parameterless procedures
as handlers (other types of handlers may be provided by the implementation,
but are not required by the standard), then if Old_Handler is not null,
it may be called to execute the previous handler. This provides a way
to cascade application interrupt handlers. However, the default handler
cannot be cascaded this way (Old_Handler must be null for the
The Detach_Handler procedure restores the default
treatment for the specified interrupt.
For all operations defined in this package that take
a parameter of type Interrupt_Id, with the exception of Is_Reserved and
Reference, a check is made that the specified interrupt is not reserved.
Program_Error is raised if this check fails.
If, by using the Attach_Handler, Detach_Handler, or Exchange_Handler
procedures, an attempt is made to detach a handler that was attached
statically (using the aspect pragma
Attach_Handler), the handler is not detached and Program_Error is raised.
The Reference function returns a value of type System.Address that can
be used to attach a task entry,
via an address
clause (see J.7.1
) to the interrupt specified
by Interrupt. This function raises Program_Error if attaching task entries
to interrupts (or to this particular interrupt) is not supported.
The function Get_CPU returns the processor on which
the handler for Interrupt is executed. If the handler can execute on
more than one processor the value System.Multiprocessors.Not_A_Specific_CPU
At no time during attachment or exchange of handlers
shall the current handler of the corresponding interrupt be undefined.
If the Ceiling_Locking policy (see D.3
the implementation shall document
the default ceiling priority assigned to a protected object that contains
a protected procedure that specifies
the Attach_Handler or Interrupt_Handler aspects pragmas
but does not specify not
the Interrupt_Priority aspect pragma
[This default need not be the same for all interrupts.]
Documentation Requirement: If
the Ceiling_Locking policy is in effect, the default ceiling priority
for a protected object that specifies contains an interrupt handler aspect pragma.
If implementation-defined forms of interrupt handler
procedures are supported, such as protected procedures with parameters,
then for each such form of a handler, a type analogous to Parameterless_Handler
should be specified in a child package of Interrupts, with the same operations
as in the predefined package Interrupts.
If implementation-defined forms of interrupt
handler procedures are supported, then for each such form of a handler,
a type analogous to Parameterless_Handler should be specified in a child
package of Interrupts, with the same operations as in the predefined
8 The package Interrupts.Names contains
implementation-defined names (and constant values) for the interrupts
that are supported by the implementation.
Example of interrupt
Device_Priority : constant
(1..5) of System.Interrupt_Priority := ( ... );
(Int_Id : Ada.Interrupts.Interrupt_Id)
with Interrupt_Priority => Device_Priority(Int_Id) is
with Attach_Handler => Int_Id;
pragma Attach_Handler(Handler, Int_Id)
Device_1_Driver : Device_Interface(1);
Device_5_Driver : Device_Interface(5);
Wording Changes from Ada 95
Corrigendum: Clarified that the value returned
by Current_Handler and Exchange_Handler for the default treatment is
Incompatibilities With Ada 2005
Functions Get_CPU is newly
added to Interrupts. If Interrupts is referenced in a use_clause,
and an entity E with a defining_identifier
of Get_CPU is defined in a package that is also referenced in a use_clause,
the entity E may no longer be use-visible, resulting in errors.
This should be rare and is easily fixed if it does occur.
Ada 2005 and 2012 Editions sponsored in part by Ada-Europe