Next: Operations Violating Package Locks, Previous: Package Lock Violations, Up: Package Lock Concepts
Compiling lexical binding constructs or lexical declarations that
violate package locks causes a compile-time package-lock violation. A
complete listing of operators affect by this is: let
,
let*
, flet
, labels
, macrolet
, and
symbol-macrolet
, declare
.
Package locks affecting both lexical bindings and declarations can be
disabled at compile-time with sb-ext:disable-package-locks
declaration, and re-enabled with sb-ext:enable-package-locks
declaration. Constructs compiled with package locks thusly disabled
are guaranteed not to signal package lock violation errors at runtime.
Example:
(in-package :locked) (defun foo () ...) (defmacro with-foo (&body body) `(locally (declare (disable-package-locks locked:foo)) (flet ((foo () ...)) (declare (enable-package-locks locked:foo)) ; re-enable for body ,@body)))
If file-compiled code contains interned symbols, then loading that code into an image without the said symbols will not cause a package lock violation, even if the packages in question are locked.
With the exception of the aforementioned contructs, and interned symbols, behaviour is unspecified if package locks affecting compiled code are not the same during loading of the code or execution.
Specifically, code compiled with packages unlocked may or may not fail to signal package-lock-violations even if the packages are locked at runtime, and code compiled with packages locked may or may not signal spurious package-lock-violations at runtime even if the packages are unlocked.
In practice all this means that package-locks have a neglible performance penalty in compiled code as long as they are not violated.