Locking discussed in this section has nothing to do with
MT:MUTEX-LOCK
.
Function EXT:PACKAGE-LOCK
. Packages can be “locked”.
When a package is locked, attempts to change its symbol table or
redefine functions which its symbols name result in a continuable ERROR
(continuing overrides locking for this operation).
When CUSTOM:*SUPPRESS-CHECK-REDEFINITION*
is T
(not a good idea!), the ERROR
is not SIGNAL
ed for redefine operations.
Function (
returns the generalized boolean indicating whether the EXT:PACKAGE-LOCK
package
)package
is locked.
A package (or a list thereof) can be locked using (
.
CLISP locks its system packages (specified in the variable
SETF
(EXT:PACKAGE-LOCK
package-or-list
) T
)CUSTOM:*SYSTEM-PACKAGE-LIST*
).
Macro EXT:WITHOUT-PACKAGE-LOCK
. If you want to evaluate some forms with certain packages unlocked,
you can use
EXT:WITHOUT-PACKAGE-LOCK
:
(EXT:WITHOUT-PACKAGE-LOCK
(“COMMON-LISP” “EXT” “CLOS”)
(defun restart () ...))
or
(EXT:WITHOUT-PACKAGE-LOCK
(“COMMON-LISP”) (trace read-line))
(
temporarily unlocks all packages in EXT:WITHOUT-PACKAGE-LOCK
() ...)CUSTOM:*SYSTEM-PACKAGE-LIST*
.
Variable CUSTOM:*SYSTEM-PACKAGE-LIST*
. This variable specifies the default packages to be locked by EXT:SAVEINITMEM
and unlocked by EXT:WITHOUT-PACKAGE-LOCK
as a list of package names.
You may add names to this list, e.g., a module will add its package,
but you should not remove CLISP internal packages from this list.
Discussion - see also the USENET posting by . This should prevent you from accidentally hosing yourself with
(DEFSTRUCT
instance ...)
and allow enforcing modularity.
Note that you will also get the continuable ERROR
when you try to
assign (with SETQ
, PSETQ
, etc.) a value to an internal special
variable living in a locked package and not accessible in your current
*PACKAGE*
, but only in the interpreted code and during compilation.
There is no check for package locks in compiled code because of the
performance considerations.
These notes document CLISP version 2.49 | Last modified: 2010-07-07 |