Module Index ||
Search Engine ||
Ulm's Oberon Library:
Priorities - priority system for events
CONST region = 10;
CONST gap = 10;
TYPE Priority = INTEGER;
VAR base: Priority;
VAR default: Priority;
VAR message: Priority;
VAR syserrors: Priority;
VAR liberrors: Priority;
VAR assertions: Priority;
VAR error: Priority;
VAR interrupts: Priority;
VAR storage: Priority;
VAR rtserrors: Priority;
VAR fatal: Priority;
VAR fatalsignals: Priority;
VAR bug: Priority;
VAR taskswitch: Priority;
VAR exit: Priority;
defines the priority system of the Oberon library
per initialized variables.
The original module can be copied and modified to match
the needs of a specific application.
This is necessary in cases where e.g. library errors should get
higher priority than asynchronous interrupts.
The priority values are not consecutive to be open for
Each priority given below defines a base value of a priority region.
The region size is defined by
region, e.g. library error priorities range from
liberrors+region-1. To allow insertion of new priority levels there is a minimum distance
between two priority regions (gap).
Some rules for ordering priority values:
Events with higher severity should have higher priority levels,
e.g. segmentation violations should be at higher level than
the interrupts (break key).
Some events allow a level-oriented generalized error handling
These events must be at higher priority than those events
which lead to errors.
E.g. error should be at higher priority than liberrors,
fatal at higher priority than storage, and
bug at higher priority than fatalsignals.
Events raised at an higher abstraction level should have higher
priority than low-level events.
E.g. liberrors should be at higher priority than
The following list of prioritities is in ascending order.
Current priority at beginning of execution
(after initialization of Events).
This is the lowest priority possible during execution.
Every event with priority less than base is ignored
Default priority of events.
The priority of an event can be changed using Events.SetPriority.
Priority of messages which do not indicate an error.
Priority of system call errors.
It is convention in the Oberon system library that
events are raised for failed system calls
(which are ignored by default).
Priority of library errors,
e.g. usage errors or failed system calls.
Library errors should have higher priority than syserrors.
Priority of failed assertions inside library.
Conventionally, failed assertions are handled by Assertions.
Priority of (application) error messages or warnings.
Priority of asynchronous interrupts like break key, alarm clock, etc.
Priority of "out of space" events (SysStorage)
Priority of runtime errors.
Priority of fatal errors which lead to an error message and
Priority of fatal signals.
These are UNIX signals where return would cause an infinite loop,
e.g. segmentation violation, alignment fault, and illegal instruction.
Priority of bugs and (failed) assertions.
Bugs are error messages followed by program termination
(with core dump if possible).
This priority was used formerly by Tasks but
is now obsolete.
Priority of exit (SysProcess.Exit) and abort (SysProcess.Abort).
Actions on this priority level should be minimized
and (if possible) error-free.
handling of failed assertions
standardized handling of error events
priority driven event handler
handling of program termination (exit)
raise of runtime errors (rtserrors)
standardized handling of system errors
UNIX signals (interrupts and fatalsignals)
memory management (storage)
definition of Priorities
module of Priorities
Edited by: borchert, last change: 1996/09/13, revision: 1.6, converted to HTML: 1997/04/28
Module Index ||
Search Engine ||