David Lichteblau <david@...> writes:
> This is probably just another case of the GC problems discussed on this
> list earlier (in that case sorry for the noise) but in a slightly
> different form:
No, this is definitely different.
> - This is SBCL 0.8.7.2, which is not affected by the test cases posted
> earlier here by Paul F. Dietz and others.
> - But running GC in a thread makes the initial listener suspend itself
> is if it had received SIGTSTP or SIGSTOP.
> * (sb-thread:make-thread (lambda () (sb-ext:gc :full t)))
> + Stopped sbcl --userinit /dev/null
Hmm. It suspends itself as if it had received SIGSTOP, well, because
it _does_ receive SIGSTOP -- part of the process of undergoing GC is
that all of the threads other than the thread executing the GC are
stopped. In this case, the "background" thread is the one executing the
GC, presumably, so the "foreground" thread receives a SIGSTOP.
Is there some unix process magic that we can use to tell the shell
that a SIGSTOP isn't enough to deforeground sbcl (unless it's from a
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)