- (if (thread-alive-p thread)
- (let* ((offset (* sb!vm:n-word-bytes
- (sb!vm::symbol-tls-index symbol)))
- (tl-val (sap-ref-word (%thread-sap thread) offset)))
- (if (eql tl-val sb!vm::no-tls-value-marker-widetag)
- (values nil :unbound)
- (values (make-lisp-obj tl-val) :bound)))
- (values nil :dead))))
+ (loop
+ (if (thread-alive-p thread)
+ (let* ((epoch sb!kernel::*gc-epoch*)
+ (offset (* sb!vm:n-word-bytes
+ (sb!vm::symbol-tls-index symbol)))
+ (tl-val (sap-ref-word (%thread-sap thread) offset)))
+ (cond ((zerop offset)
+ (return (values nil :no-tls-value)))
+ ((or (eql tl-val sb!vm:no-tls-value-marker-widetag)
+ (eql tl-val sb!vm:unbound-marker-widetag))
+ (return (values nil :unbound-in-thread)))
+ (t
+ (multiple-value-bind (obj ok) (make-lisp-obj tl-val nil)
+ ;; The value we constructed may be invalid if a GC has
+ ;; occurred. That is harmless, though, since OBJ is
+ ;; either in a register or on stack, and we are
+ ;; conservative on both on GENCGC -- so a bogus object
+ ;; is safe here as long as we don't return it. If we
+ ;; ever port threads to a non-conservative GC we must
+ ;; pin the TL-VAL address before constructing OBJ, or
+ ;; make WITH-ALL-THREADS-LOCK imply WITHOUT-GCING.
+ ;;
+ ;; The reason we don't just rely on TL-VAL pinning the
+ ;; object is that the call to MAKE-LISP-OBJ may cause
+ ;; bignum allocation, at which point TL-VAL might not
+ ;; be alive anymore -- hence the epoch check.
+ (when (eq epoch sb!kernel::*gc-epoch*)
+ (if ok
+ (return (values obj :ok))
+ (return (values obj :invalid-tls-value))))))))
+ (return (values nil :thread-dead))))))