|Did you know ...||Search Documentation:|
|Reloading files, active code and threads|
Traditionally, Prolog environments allow for reloading files holding currently active code. In particular, the following sequence is a valid use of the development environment:
Reloading a previously loaded file is safe, both in the debug scenario above and when the code is being executed by another thread. Executing threads switch atomically to the new definition of modified predicates, while clauses that belong to the old definition are (eventually) reclaimed by garbage_collect_clauses/0.59As of version 7.3.12. Older versions wipe all clauses originating from the file before loading the new clauses. This causes threads that executes the code to (typically) die with an undefined predicate exception. Below we describe the steps taken for reloading a file to help understanding the limitations of the process.
meta_predicateare in part applied immediately and in part during the fixup process after the file completes loading. Currently,
thread_localare applied immediately.
The above generally ensures that changes to the content of source files can typically be activated safely using make/0. Global changes such as operator changes, changes of module names, changes to multi-file predicates, etc. sometimes require a restart. In almost all cases, the need for restart is indicated by permission or syntax errors during the reload or existence errors while running the program.
In some cases the content of a source file refers‘to itself'.
This is notably the case if local rules for goal_expansion/2
are defined or goals are executed using
directives.60Note that initialization/1
directives are executed after loading the file. SWI-Prolog
allows for directives that are executed while loading the file
:- Goal. or initialization/2.
Up to version 7.5.12 it was typically needed to reload the file twice,
once for updating the code that was used for compiling the remainder of
the file and once to effectuate this. As of version 7.5.13, conventional transaction
semantics apply. This implies that for the thread performing the
reload the file's content is first wiped and gradually rebuilt, while
other threads see an atomic update from the old file content to
the new.61This feature was
implemented by Keri Harris.
Errors and warnings reported while compiling a file are reported using print_message/2. Typical errors are syntax errors, errors during macro expansion by term_expansion/2 and goal_expansion/2, compiler errors such as illegal clauses or an attempt to redefine a system predicate and errors caused by executing directives, notably using initialization/1 and initialization/2.
Merely reporting error messages and warnings is typically desirable for interactive usage. Non-interactive applications often require to be notified of such issues, typically using the exit code of the process. We can distinguish two types of errors and warnings: (1) those resulting from loading an invalid program and (2) messages that result from running the program. A typical example is user code that wishes to try something and in case of an error report this and continue.
..., E = error(_,_), catch(do_something, E, print_message(error, E)), ...
User code may be (and often is) started from directives, while running user code may involve compilation due to autoloading, loading of data files, etc. As a result, it is unclear whether an error message should merely be printed, should result in a non-zero exit status at the end or should immediately terminate the process.
The default behaviour is defined by the Prolog flags
on_error and on_warning.
It can be fine tuned by defining the hook predicate message_hook/3.
The compiler calls print_message/2
using the level
silent and the message below if errors or
warnings where printed during the execution of
library(lists), Errors is the number of errors printed while loading and Warnings is the number of warnings printed while loading. Note that these counts include messages from (initialization) directives.
This allows the user to fine tune the behaviour on errors and, for example, halt the process on a non-zero error count right after loading the file wth errors using the code below.
:- multifile user:message_hook/3. user:message_hook(load_file_errors(_File, Errors, _Warnings), _Level, _Lines) :- Errors > 0, halt(1).
Large programs are generally split into multiple files. If file A
accesses predicates from file B which accesses predicates
A, we consider this a mutual or circular dependency. If
traditional load predicates (e.g., consult/1)
are used to include file B from A and A
from B, loading either file results in a loop. This is
is mapped to load_files/2
using the option
if(true)(.) Such programs are typically
loaded using a load file that consults all required
(non-module) files. If modules are used, the dependencies are made
explicit using use_module/1
predicate, however, maps to load_files/2
with the option
if(not_loaded)(.) A use_module/1
on an already loaded file merely makes the public predicates of the used
Summarizing, mutual dependency of source files is fully supported with no precautions when using modules. Modules can use each other in an arbitrary dependency graph. When using consult/1, predicate dependencies between loaded files can still be arbitrary, but the consult relations between files must be a proper tree.
This section discusses compiling files for the first time. For reloading, see section 4.3.2.
Multiple threads can compile files concurrently. This requires special precautions only if multiple threads wish to load the same file at the same time. Therefore, load_files/2 checks whether some other thread is already loading the file. If not, it starts loading the file. If a thread detects that another thread is already loading the file the thread blocks until the other thread finishes loading the file. After waiting, and if the file is a module file, it imports the exported predicates and operators from the module.
Note that this schema does not prevent deadlocks under all situations. Consider two mutually dependent (see section 220.127.116.11) module files A and B, where thread 1 starts loading A and thread 2 starts loading B at the same time. Both threads will deadlock when trying to load the used module.
The current implementation does not detect such cases and the involved threads will freeze. This problem can be avoided if a mutually dependent collection of files is always loaded from the same start file.