From: Juho Snellman <jsnell@us...> - 2006-09-13 21:37:32
Update of /cvsroot/sbcl/sbcl/src/code
In directory sc8-pr-cvs8.sourceforge.net:/tmp/cvs-serv18159/src/code
The new timer.impure test added in 0.9.16.21 uncovered some
completely unrelated problems in a different test. Multiple
simultaneous FIND-SYMBOLs on the same package could cause the
package to become corrupted in a way that would cause further
accesses to it to loop infinitely. This seems a bit harsh.
* Remove the optimization (moving the table from which a
symbol was found to the front of the package's table list)
which was causing this problem. It didn't seem to have much
of an performance effect anyway.
* Fix the test that was accidentally triggering this bug and
add a new test specifically for it.
RCS file: /cvsroot/sbcl/sbcl/src/code/target-package.lisp,v
retrieving revision 1.36
retrieving revision 1.37
diff -u -d -r1.36 -r1.37
--- target-package.lisp 1 Oct 2005 13:01:11 -0000 1.36
+++ target-package.lisp 13 Sep 2006 21:37:28 -0000 1.37
@@ -694,8 +694,7 @@
(values symbol nil))))))))
;;; Check internal and external symbols, then scan down the list
-;;; of hashtables for inherited symbols. When an inherited symbol
-;;; is found pull that table to the beginning of the list.
+;;; of hashtables for inherited symbols.
(defun find-symbol* (string length package)
(declare (simple-string string)
(type index length))
@@ -716,8 +715,20 @@
((null table) (values nil nil))
(with-symbol (found symbol (car table) string length hash ehash)
- (unless (eq prev head)
- (shiftf (cdr prev) (cdr table) (cdr head) table))
+ ;; At this point we used to move the table to the
+ ;; beginning of the list, probably on the theory that we'd
+ ;; soon be looking up further items there. Unfortunately
+ ;; that was very much non-thread safe. Since the failure
+ ;; mode was nasty (corruption of the package in a way
+ ;; which would make symbol lookups loop infinitely) and it
+ ;; would be triggered just by doing reads to a resource
+ ;; that users can't do their own locking on, that code has
+ ;; been removed. If we ever add locking to packages,
+ ;; resurrecting that code might make sense, even though it
+ ;; didn't seem to have much of an performance effect in
+ ;; normal use.
+ ;; -- JES, 2006-09-13
(return-from find-symbol* (values symbol :inherited))))))))
;;; Similar to FIND-SYMBOL, but only looks for an external symbol.