Next: , Previous: Package Lock Violations, Up: Package Lock Concepts



9.1.4 Package Locks in Compiled Code

9.1.4.1 Lexical bindings and declarations

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)))
9.1.4.2 Interned symbols

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.

9.1.4.3 Other limitations on compiled code

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.