Mode Handling

The programming interface allows mode changes from a secondary thread. The secondary thread acts as a controller of the primary thread. By changing the mode it controls the behav-iour of the primary thread. A typical example of a secondary thread is the user interface event thread. The primary threads are then the console window Prolog threads. The secondary thread can then for example start tracing a console window Prolog thread by changing into an appropriate mode.

The normal flow allows that mode changes can happen at any time. Their effect is also not delimited to the call port of a predicate or to an interrupted blocking operation. This is not very problematic except when inside a trace handler. A mode change might cause an undesired invocation of the trace handler. The system predicate sys_ignore/1 allows calling a goal with the mode cloak mask temporarily set off.

The following modehandling predicates are provided:

sys_ignore(A):
The predicate succeeds whenever A succeeds. The goal A is invoked with the mode cloak temporarily set to off.

The following Prolog flags for mode handling are provided:

sys_cloak:
Legal values are on and off. The flag indicates whether the interpreter currently accepts mode changes. Default value is on. The value cannot be changed.
sys_clause_instrument:
Legal values are on and off. The flag is per knowledge base and is inherited when predicates are created. Default value is on. The value can be changed.
sys_head_wakeup:
Legal values are on and off. The flag is per knowledge base and is inherited when predicates are created. Default value is on. The value can be changed.

The following mode handling predicate properties are provided:

sys_noinstrument:
The property indicates that the clauses of the predicate should not be instrumented for debugging. The value can be changed.
sys_nowakeup:
The property indicates that frozen goals should not be woken up after the head of the clause is unified. The value can be changed.
Add 

Comments