C.3.2 The Package Interrupts
The following language-defined
with Nonblocking is
Interrupt_Id is implementation-defined
access protected procedure
with Nonblocking => False
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)
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
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
is restored. If New_Handler designates a protected procedure for which
the aspect Interrupt_Handler is False, 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
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
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 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 is returned.
At no time during attachment or exchange of handlers
shall the current handler of the corresponding interrupt be undefined.
The implementation shall document, when If
the Ceiling_Locking policy (see D.3
) is in
effect, the implementation shall document
the default ceiling priority assigned to a protected object that contains
a protected procedure that specifies either the Attach_Handler or Interrupt_Handler
aspects, but does not specify the Interrupt_Priority aspect. [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 an interrupt handler aspect.
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.
Implementation Advice: 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 package Interrupts.
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 of
System.Interrupt_Priority := ( ... );
(Int_Id : Ada.Interrupts.Interrupt_Id)
Interrupt_Priority => Device_Priority(Int_Id) is
Attach_Handler => Int_Id;
Device_1_Driver : Device_Interface(1);
Device_5_Driver : Device_Interface(5);
Wording Changes from Ada 95
Clarified that the value returned by Current_Handler
and Exchange_Handler for the default treatment is null.
Incompatibilities With Ada 2005
Function Get_CPU is 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