[Ecls-list] Special symbols that might benefit from implicit locking or thread-local bindings

[Matthew Mondor]

On Mon, 1 Aug 2011 14:05:39 +0200
Juan Jose Garcia-Ripoll <juanjose.garciaripoll at googlemail.com> wrote:

> Even *PACKAGE* might not need to be thread-local. The place where *package*
> is most used is in loaded code, within IN-PACKAGE statements, but LOAD binds
> *PACKAGE*, both in binary and in source files, so it automatically becomes
> thread-local. User code should also bind *PACKAGE*, both when reading and
> when printing, because otherwise the code may suddenly break when used in
> the wrong context... So maybe after all there are not that many special
> variables that need protection if one restricts to LET-bindings instead of
> just SETF.

And indeed in the code I found via quick greps 72 uses of *PACKAGE*,
of which there seems to be at least 23 instances of let/bind already:

contrib/asdf/asdf-ecl.lisp:406:      (let ((*package* (find-package :keyword)))
contrib/asdf/asdf.lisp:1337:           (let ((*package* package))
contrib/asdf/asdf.lisp:2123:  (let* ((*package* *package*)
contrib/bytecmp/bytecmp.lsp:91:        (let ((binary (loop with *package* = *package*
contrib/defsystem/defsystem.lisp:4380:      (let ((warn-packs system::*packages-for-warn-on-redefinition*))
src/clos/conditions.lsp:886:         (do ((form (let ((*package* (find-package "keyword")))
src/clx/demo/clx-demos.lisp:96:        `(let ((*package* *keyword-package*))
src/clx/dep-allegro.lisp:1286:  (let ((*package* (find-package :user))
src/clx/dependent.lisp:3010:  (let ((*package* (find-package :user))
src/cmp/cmptop.lsp:600:          for name = (let ((*package* (find-package "KEYWORD")))
src/lsp/defpackage.lsp:200:  (let ((*package* (find-package name)))
src/lsp/describe.lsp:534:           (let ((*package* (good-package)))
src/lsp/describe.lsp:547:           (let ((*package* (good-package)))
src/lsp/describe.lsp:552:           (let ((*package* (good-package)))
src/lsp/describe.lsp:557:           (let ((*package* (good-package)))
src/lsp/export.lsp:167:  (let ((feature (let ((*package* (find-package "KEYWORD")))
src/lsp/helpfile.lsp:20:  (let* ((*package* (find-package "CL"))
src/lsp/helpfile.lsp:53:    (let* ((*package* (find-package "CL"))
src/lsp/helpfile.lsp:85:    (let* ((*package* (find-package "CL"))
src/lsp/packlib.lsp:205:        (let ((p *package*))
src/lsp/top.lsp:980:                         (let ((*package* (find-package "KEYWORD")))
src/new-cmp/cmpc-ops.lsp:599:          for name = (let ((*package* (find-package "KEYWORD")))
src/c/load.d:280:       ecl_bds_bind(the_env, @'*package*', ecl_symbol_value(@'*package*'));


With only about 13 cases of setf/setq:

contrib/cl-simd/ecl-sse-core.lisp:174:         (rm-aset-name (intern (format nil "ROW-MAJOR-ASET-~A" tag) *package*))
contrib/defsystem/defsystem.lisp:4019:            (setf *package* package)))))
contrib/defsystem/defsystem.lisp:4100:      (setf *package* (find-package old-package)))
contrib/defsystem/defsystem.lisp:4382:  (setq system::*packages-for-warn-on-redefinition* nil)
contrib/defsystem/defsystem.lisp:4388:  (setq system::*packages-for-warn-on-redefinition* warn-packs))
src/bare.lsp.in:34:(setq *package* (find-package "SYSTEM"))
src/c/cinit.d:144:      ECL_SET(@'*package*', cl_core.system_package);
src/c/main.d:699:       ECL_SET(@'*package*', cl_core.lisp_package);
src/c/main.d:708:       ECL_SET(@'*package*', cl_core.user_package);
src/c/package.d:339:            ECL_SETQ(env, @'*package*', cl_core.user_package);
src/c/package.d:841:    @(return (ECL_SETQ(the_env, @'*package*', p)))
src/compile.lsp.in:13:  (setq *package* (find-package "SYSTEM"))
src/lsp/defpackage.lsp:202:      (setf (documentation *package* t) documentation))

We probably should determine if those SET cases are justified or if
they also should be dynamic bindings...  Although, if strategic places
establish a new binding like you said, such as the thread prologue,
toplevel, compiler, loader, etc, any set case would in theory be
harmless too.
-- 
Matt