11.2. Constraints on the COMMON-LISP Package for Conforming Programs - package locking [sec_11-1-2-1-2]


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 SIGNALed for redefine operations. Function (EXT:PACKAGE-LOCK package) returns the generalized boolean indicating whether the package is locked. A package (or a list thereof) can be locked using (SETF (EXT:PACKAGE-LOCK package-or-list) T). CLISP locks its system packages (specified in the variable 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 :

  (defun restart () ...))



(EXT:WITHOUT-PACKAGE-LOCK () ...) temporarily unlocks all packages in 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 Steven M. Haflich. 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.49Last modified: 2010-07-07