* Raymond Toy [2012-02-01 03:27] writes:
Yeah, that looks like a bug. I think the problem is not with gc, but with the signal handler(s). I was planning on doing some work on the signal handlers to make them simpler, based on what Carl did for Windows. This should make them simpler and safer. Don't know if it will take care of this problem or not.
The problem doesn't occur with an empty loop. Therefore I think it has something to do with GC.
29 SIGIO
SLIME uses SIGIO on a socket and if that stays blocked then SLIME can't interrupt the Lisp process. Also note that C-z in the terminal doesn't
Does SIGIO actually work for you? I stopped using it long ago because it caused strange errors to occur (on darwin). I think it's because SIGIO causes interrupts at bad places because cmucl isn't really interrupt-safe.
Works good enough for me (on Linux). The GC should of course be interrupt-safe. The stream code is not reentrant so it is problematic to use streams in signal handlers. SLIME tries to be careful when reading/writing to it's own stream and tries to delay interrupts to safe-points. SLIME can't fix other streams or non-reentrant code, but the situation there is IMO the same as if the debugger is invoked with SIGINT. Helmut