Custom Query (1030 matches)

When using a trunk darwinx8664 lisp at r15433 on Mountain Lion, slime often takes tens of seconds to start up.

At a quick first glance, I observe that allocate_tcr() often ends up looping hundreds of thousands, or even millions, of times before it gets a TCR that has a suitable address to use as a Mach port name.

Slime creates several threads at a startup, and usually a few of them end up taking a while to get going. Crudely instrumenting allocate_tcr() shows that the time to find a suitable port name can take anywhere from under a second to 20 seconds or more.

Dan Weinreb 2009-09-08 15:09:04 EDT

delete-package, when called on a name that does not name a package, should return nil according to the Common Lisp hyperspec rather than signal a condition (for better or worse). Instead, it signals.

Comment 1 Ethan H. Schwartz 2009-09-10 17:22:03 EDT

from ​http://www.lispworks.com/documentation/HyperSpec/Body/f_del_pk.htm#delete-package:

Exceptional Situations:

If the package designator is a name that does not currently name a package, a correctable error of type package-error is signaled. If correction is attempted, no deletion action is attempted; instead, delete-package immediately returns nil.

[NB1: there are other exceptional situations in the CLHS]

[NB2: this was ITA bug 67561]

(dotimes (i 1000)
  (if (evenp i)
    (process-run-function
      "creator"
      (lambda ()
        (ignore-errors (delete-package :foo))
        (make-package :foo)))
    (process-run-function
      "user"
      (lambda ()
        (ignore-errors (intern "FOO" :foo))))))

Running this a time or two in an x8632 lisp results in errors of the form:

> Error: Fault during read of memory address #x-34F3EA94
> While executing: DELETE-PACKAGE, in process creator(1458).

It appears that delete-package reads/modifies %all-packages% without using the associated locks.