Suspensions

ECLiPSe provides an opaque data type, called suspension, to represent suspended goals. Although usually a suspended goal waits for some waking condition in order to be reactivated, the primitives for suspension handling do not enforce this. To provide maximum flexibility of use, the functionalities of suspending and waking/scheduling are separated from the trigger mechanisms that cause the waking. We first describe the operations on suspensions.

What's in a Suspension?

A suspension represents a goal that is part of the resolvent. Apart from the goal structure proper, it holds information that is used for controlling its execution. The components of a suspension are:

The goal structure

A term representing the goal itself, eg. X >Y.

The goal module

The module from which the goal was called.

The goal priority

The priority with which the goal will be scheduled when it becomes woken.

The state

This indicates the current position of the suspension within the resolvent. It is either suspended (sleeping), scheduled or executed (dead).

Debugger data

Creating Suspended Goals

The most basic primitive to create a suspension is make_suspension(Goal, Priority, Susp [, Module]) where Goal is the goal structure, Priority is a small integer denoting the priority with which the goal should be woken and Susp is the resulting suspension.

Note that usually make_suspension/3,4 is not used directly, but implicitly via suspend/3,4 (described below) which in addition attaches the suspension to a trigger condition.

A suspension which has not yet been scheduled for execution and executed, is called sleeping, a suspension which has already been executed is called executed or dead (since it disappears from the resolvent). A newly created suspension is always sleeping, however note that due to backtracking, an executed suspension can become sleeping again. Sometimes we use the term waking, which is less precise and denoted the process of both scheduling and eventual execution.

Operations on Suspensions

The following summarises the predicates that can be used to create, test, decompose and destroy suspensions.

make_suspension(Goal, Priority, Susp)

make_suspension(Goal, Priority, Susp, Module)

Create a suspension Susp with a given priority from a given goal. The goal will subsequently show up as a delayed goal.

is_suspension(Susp)

Succeeds if Susp is a sleeping or scheduled suspension, fails if it is a suspension that has been already executed.

type_of(S, goal)

Succeeds if S is a suspension, no matter if it is sleeping, scheduled or executed.

get_suspension_data(Susp, Name, Value)

Extract any of the information contained in the suspension: Name can be one of goal, module, priority, state or invoc.

set_suspension_data(Susp, Name, Value)

The priority and invoc (debugger invocation number) fields of a suspension can be changed using this primitive. If the priority of a sleeping suspension is changed, this will only have an effect at the time the suspension gets scheduled. If the suspension is already scheduled, changing priority has no effect, except for future schedulings of demons (see 17.7).

kill_suspension(Susp)

Convert the suspension Susp into an executed one, ie. remove the suspended goal from the resolvent. This predicate is meta-logical as its use may change the semantics of the program.

Examining the Resolvent

The system keeps track of all created suspensions and it uses this data e.g. in the built-in predicates delayed_goals/1, suspensions/1, current_suspension/1, subcall/2 and to detect floundering of the query given to the ECLiPSe top-level loop. A query is said to flounder if it succeeds but leaves some unexecuted suspensions. In this case, the answer substitutions alone do not form a solution, the suspended goals have to be taken in to account as well.