Christophe Rhodes <csr21@...> writes:
> As you may know, I at least get occasional failures in
> threads.impure.lisp. Today I found what I think is an error in
> interrupt-thread -- at least, if it's not an error, I'd like to know
> why it isn't.
You know, this gets funnier. I convinced myself that I didn't need
this patch on the train back to Cambridge. Why? Let's look at this:
(defun interrupt-thread (thread function)
"Interrupt THREAD and make it run FUNCTION. "
(coerce function 'function))))
GET-LISP-OBJ-ADDRESS is known (src/compiler/generic/vm-fndb.lisp) to
return an object of (unsigned-byte 32). So clearly it ought to be
held in a register, or on the stack, between returning from
get-lisp-obj-address and having interrupt_thread be called; so, given
the x86 gencgc's conservatism, the function ought never to move.
This reasoning falls down when confronted with reality, however: SBCL
seems not to have chosen an unboxed representation for the return
value of GET-LISP-OBJ-ADDRESS, so the WITH-PINNED-OBJECTS I proposed
in my patch is, I think, necessary. So my question really is: why
doesn't sbcl choose an unboxed representation?
(Since it is patently necessary, I'll check in my patch soon).
http://www-jcsu.jesus.cam.ac.uk/~csr21/ +44 1223 510 299/+44 7729 383 757
(set-pprint-dispatch 'number (lambda (s o) (declare (special b)) (format s b)))
(defvar b "~&Just another Lisp hacker~%") (pprint #36rJesusCollegeCambridge)
Get latest updates about Open Source Projects, Conferences and News.